SingleSource Technologie versus Repository
Repositories gelangen heute mehr und mehr in die fachliche Diskussion, obwohl sie bereits seit 20 Jahren in der Softwareentwicklung eingesetzt werden. Die Bewertung des Nutzens fällt oftmals sehr unterschiedlich aus und ist direkt vom Einsatzzweck abhängig. Neue Technologien wie die Singlesource-Technologie drängen auf den Markt und bringen zukunftsorientierte Betrachtungsweisen in den objektorientierten Softwareentwicklungsprozeß. In wieweit ist die Singlesource-Technologie eine Ablösung für renommierte Repositories oder ergänzen sich beide Technologien.
Dieser Artikel beschäftigt sich unter anderem mit den Fragen:
-
Was ist ein Repository und welche Typen von Repositories gibt es?
-
Wofür wird es eingesetzt?
-
Wie ist die zukünftigen Entwicklung?
-
Wie bewertet man den Nutzen für den Softwareentwicklungsprozeß?
-
Welche neuen Technologien und Ansätze für Repositories gibt es?
Im umgangssprachlichen Bereich wird das Repository im Sinne eines strukturierten Datenspeichers verwendet. Bei weiterer Konkretisierung erkennt man die Zuordnung im Softwareentwicklungsprozeß zu den Projektphasen Definition von Anforderungen, Spezifikation und Analyse. Auch im Bereich des Business-Prozeß-Reengineering trifft man vielfach auf den Begriff des Repositories. Diese Projektphasen wollen wir als Modellierungsphasen und das Repository als Modellierungs-Repository bezeichnen.
Alle diese Anwendungsbereiche haben eines gemeinsam: Sie benötigen ein strukturiertes Medium zur Speicherung abstrakter Anforderungen, Spezifikationen und Analyse-Ergebnisse. Da all diese Informationen eine hohe Vernetzung untereinander aufweisen, vordefinierte Strukturen haben und anhand von Stichworten, sogenannten Fachtermini, wiedergefunden werden müssen, werden normalerweise Datenbanksysteme für diese Aufgaben eingesetzt.
Abbildung 1: Modellierungs-Repository
Schnell trifft man bei diesem Thema auf Werkzeuge zur Unterstützung dieser Modellierungsphasen, sogenannte CASE- (Computer-Aided Software-Engineering) und BPR- (Business Process Reengineering) Werkzeuge. Diese Werkzeuge gehen über die Verwaltung von textuellen Informationen und Dokumentationen weit hinaus. Sie bieten leistungsfähige graphische Editoren zur Abbildung von statischen und dynamischen Zusammenhängen an und ermöglichen somit eine wesentliche Verbesserung der Übersicht bei abstrakten Softwaresystemen. Die Verwaltung und Bearbeitung von textuellen Informationen zur Beschreibung der Anforderungen wird in Verbindung mit graphischen Modellen zur aussagefähigen Dokumentation des gewünschten Zielsystems. Ferner ermöglichen Konsistenzchecks die einfache Prüfung auf logische Korrektheit des Systems und unterstützt die Erstellung fachlich vollständiger Anforderungen.
-
Unternehmensweiter Zugriff auf relevante unternehmensübergreifende Daten
-
Leistungsfähige Multiuser- und Zugriffssteuerung
-
Hohe Datenintegrität und Konsistenz der Informationen
-
Abbildung von Vorgehensmodellen und Workflow Abhängigkeiten
-
Mangelhafte Revisionsverwaltung von Modulen
-
Problematische Versionierung über externe Revision-Control-Systeme
-
Synchronisierung von selbstständigen verteilten Entwicklungsgruppen
-
Datenaustausch und Synchronisierung mit anderen informationsverarbeitenden Systemen
Die Modellierungs-Repositories und die zugehörigen Werkzeuge unterstützen primär die frühen Phasen von Softwareprojekten. In den Realisierungsphasen wird bis heute hauptsächlich direkt mit Sourcecode auf Dateiebene gearbeitet. Diese Betrachtung gilt für 3GL-Sprachen wie C++, Java, Cobol etc. und nicht für 4GL-Entwicklungsumgebungen.
Alle Entwicklungswerkzeuge für 3GL-Sprachen wie Compiler, Linker, Debugger, Editoren, Make-Systeme und Testwerkzeuge nutzen Sourcecode-Dateien als Basis. Diese herstellerunabhängige Speicherung von Sourcecode hat sich in den letzten Jahren sehr bewährt. Die Verwaltung von Teams und Multiuser-Zugriffe werden durch ein unterlagertes Revision-Control-System hervorragend abgedeckt.
Dennoch ist die Steuerung der Granularität der Zugriffe auf Dateiebene begrenzt. Viele Sprachen haben keinerlei Abhängigkeiten der Dateistrukturen zu den im Sourcecode abgebildeten Softwarestrukturen und machen somit eine doppelte Verwaltung von Projektstrukturen notwendig.
Ein neuer Repository-Typ zur Unterstützung der Entwicklungsphasen dringt derzeit auf den Markt. Wir wollen diesen Typ im weiteren Verlauf Sourcecode-Repository nennen. Einige große Hersteller von Entwicklungsumgebungen nutzen Datenbanksysteme zur strukturierten Verwaltung des Sourcecodes in kleinen Einheiten. Innerhalb dieser Entwicklungsumgebungen bringt dies sehr große Vorteile und hohe Steigerungen der Entwicklungsgeschwindigkeit, da eine inkrementelle Compilierung die sofortige Lauffähigkeit des Zielsystems ohne Wartezeiten ermöglicht.
Abbildung 2: Unterschiedliche Typen von Repositories zur Unterstützung der Modellierungs- und Realisierungsphasen
Die Nachteile der Sourcecode-Repositories sind im Bereich der Ausgrenzung von dateibasierten Entwicklungswerkzeugen zu sehen. Viele leistungsfähige Werkzeuge wie Make-Systeme, Editoren, Testwerkzeuge können nur über den sehr problematischen und umständlichen Weg des Import/Export Datenaustausches in den Entwicklungsprozeß eingebunden werden.
Ob sich diese Sourcecode-Repositories auf dem Markt durchsetzen werden, können wir in den nächsten Jahren beobachten.
-
Feingranulare Multiuser- und Zugriffssteuerung auf Klassen, Methoden, Attribute
-
Hohe Datenintegrität und Konsistenz des Sourcecodes
-
Hohe Zeitersparnisse während der Entwicklung durch inkrementelle Compilierung
-
Verbesserung der Wiederverwendung durch leistungsfähige Such- und Zugriffsmechanismen
-
Mangelhafte Revisionsverwaltung von Modulen
-
Problematische Versionierung über externe Revision-Control-Systeme
-
Ausgrenzung sourcecodebasierender Entwicklungswerkzeuge
-
Redunanzprobleme bei Import/Export von Sourcecode
-
Herstellerabhängigkeit der gesamten Sourcecode-Verwaltung
Einer der wichtigsten Vorteile der Objektorientierung liegt in der Unterstützung iterativer (oder auch inkrementeller, evolutionärer) Entwicklungsprozesse. Die objektorientierte Technologie bietet erstmals die technischen Voraussetzungen für die Durchgängigkeit des Entwicklungsprozesses an. Mit der Objektorientierung werden erstmals methodische Vorgehensweisen mit einem nahtlosen Übergang von der Analyse, über das Design zur Implementierung (und vice versa) möglich.
Leider können diese Vorteile in der Praxis nicht genutzt werden, da die heutige Werkzeugunterstützung immer noch einen Bruch zwischen den Modellierungsphasen und den Realisierungsphasen voraussetzen.
Abbildung 3: Redundanz und fehlende Durchgängigkeit im Entwicklungsprozeß
Heute ist immer noch eine strikte Trennung der Entwicklungswerkzeuge in Modellierungsphasen und Realisierungsphasen zu verzeichnen. Bis auf eine Ausnahme, unterstützen CASE-Werkzeuge die Modellierungs-Repositories und die Entwicklungsumgebungen den Sourcecode oder ev. zukünftig Source-Repositories.
Viele Softwareentwickler sind mit dieser Trennung nicht zufrieden, da eine künstliche Datenredundanz geschaffen wird und der Entwicklungsprozeß in zwei Teile getrennt wird. Um mit der Datenredundanz fertig zu werden, muß erheblicher Aufwand investiert und eine ständige Synchronisierung durchgeführt werden.
Während der ersten Analyse-Designphase ist die noch kein Problem, da noch nicht mit sourcecodebasierenden Werkzeugen wie Compilern, Debuggern etc. gearbeitet wird. Für die dann folgende Implementierung wird aber eine Generierung des Sourcecodes aus dem Modellierungs-Repository notwendig. Ab diesem Augenblick besteht eine Datenredundanz, die nicht beherrschbar ist, da sich der Sourcecode und das Design unabhängig voneinander verändern können.
Auch die Möglichkeit des Reverse Engineering löst dieses Problem nicht. Aussagen wie Roundtrip-Engineering versuchen über diese Grundproblematik hinwegzutäuschen, da Roundtrip-Engineering-Prozesse, wie sie heute angeboten werden, nicht funktionieren. Immer ist ein Zusammenführen (Merge) von alten und neuen Strukturen notwendig. Dieser aufwendige Zusammenführungsprozeß ist aus grundlegenden Gründen nicht automatisierbar, da die semantischen Zusammenhänge von Änderungen nicht automatisch erkannt werden können.
Abbildung 4: Nutzen eines CASE-Werkzeuges im Verlauf eines Softwareprojektes
Diese Problematik dürfte einer der Hauptgründe sein, warum CASE-Werkzeuge zur Unterstützung der frühen Modellierungsphasen bis heute nicht in relevanten Marktanteilen eingesetzt werden. Die ständige Synchronisierung des Sourcecodes mit den Modellierungsdaten sind eine Belastung für den Entwicklungsprozeß und wird beim größten Teil der Softwareprojekte nicht konsequent durchgeführt. Da beim Abschluß der Projekte die Anforderungen und Analyse-Designdaten nicht mehr dem fertigen System entsprechen, wird der Nutzen von CASE-Werkzeugen vielfach in Frage gestellt.
Eine neue Technologie, Singlesource-Technologie genannt, bietet die grundsätzliche Lösung dieser Problematik an. Die Trennung der Modellierungs- und Realisierungsphasen wird durch die gemeinsame Speicherung aller Informationen des gesamten Entwicklungsprozesses in einem Speichermedium aufgehoben.
Mit der einfachen Zusammenlegung der Modellierungs- und Realisierungsinformationen ist es jedoch nicht getan. Wichtig ist die Repräsentation beider Informationen in einem gemeinsamen Meta-Modell.
Gehen wir etwas in die Tiefe und beginnen beim Ende des Softwareentwicklungsprozesses - der fertig lauffähigen Anwendung. Die lauffähige Anwendung wird durch einen eindeutig nachvollziehbaren Prozeß aus dem Sourcecode erstellt. Der Sourcecode stellt damit die einzige Ausgangsquelle dar.
Somit muß der semantische Sprachumfang des Sourcecodes alle in der lauffähigen Anwendung gewünschten Funktionalitäten abbilden können.
Wenn wir uns in der Argumentation noch einen weiteren Schritt in Richtung Anfang des Softwareentwicklungsprozesses bewegen, muß auch die Aussage richtig sein, daß alle in einer graphischen Modellierungssprache (z.B. UML, Unified Modeling Language) nutzbaren Modellierungselemente direkt oder über mehrere Zwischenstufen auf den semantischen Sprachumfang des Sourcecodes abbildbar sein müssen.
Anders ausgedrückt, muß der semantischen Sprachumfang des Sourcecodes eine klare Obermenge der graphischen Modellierungssprache sein. Wäre diese Voraussetzung nicht immer erfüllt, so könnten Anforderungen modelliert werden, die später nicht in eine lauffähige Anwendung abgebildet werden können, was per Definition nicht sehr sinnvoll wäre.
Wenn die oben gemachten Aussagen richtig sind, steht also einer Abbildung, d.h. Speicherung oder Verwaltung einer graphischen Modellierungssprache in Sourcecode, z.B. C++, Java, Delphi, OOCobol etc. nichts im Wege.
Abbildung 5: Eineindeutige Zuordnung von Sourcekonstrukten zu den Notationselementen
Reverse-Engineering mit Singlesource-Technologie
Um jedoch auch beim Reverse-Engineering des Sourcecodes die Modellierungselemente korrekt darstellen zu können, muß die Abbildung auch in der Rückwärtsrichtung eindeutig sein. D.h. um vom graphischen Modell zum Sourcecode und vom Sourcecode zum graphischen Modell zu kommen, müssen eineindeutige Abbildungsregeln vorhanden sein.
Sinnvollerweise fordern Methodenexperten wie Peter Coad und Jim Rumbaugh die Definition von Regeln, die die eindeutige Abbildung in beide Richtungen definieren um den Roundtrip-Engineering-Prozeß vollständig unterstützen zu können. Im weiteren Verlauf werden wir diese Regeln Blueprints nennen.
Abbildung 6: Blueprints zur eineindeutigen Abbildung von Sourcecode in graphische Modelle vice versa
Blueprints sind eine Art Templates, welche zu jedem Notationselement die zugehörigen Sourcecode-Konstrukte definieren.
Wie die Abbildung 5 zeigt, bieten Programmiersprachen meistens mehrere Möglichkeiten zur Umsetzung von Assoziationen oder Aggregationen. Wenn nun für jedes erlaubte Sourcecode-Konstrukt ein Blueprint definiert wird, dann können alle Sourcecode-Konstrukte im Modell dargestellt werden. Möchte man diese Konstrukte auch bei der Modellierung (Forward-Engineering!) aktiv einsetzen, so kann man jedem Blueprint ein Darstellungsattribut wie z.B. Rot, Grün, Blau, Gestrichelt zuordnen. So können Blueprints bestehende Notationen um Sourcecode-spezifische Informationen erweitern.
Als angenehmer Nebeneffekt kann beim Reengineering auf Wunsch wesentlich mehr Information wie bisher gewonnen und im Modell dargestellt werden. Die Steuerung erfolgt frei konfigurierbar durch den Einsatz von Blueprints.
Spracherweiterung durch Bibliotheken, Frameworks und Patterns
Dieses Konzept der Blueprints kann sogar um abstrakte Metastrukturen erweitert werden. Die heutigen 3GL Programmiersprachen bekommen ihre Attraktivität durch Spracherweiterungen wie z.B. Klassenbibliotheken, objektorientierten Datenbanken, Brokern, GUI-Bibliotheken und Frameworks.
Mit dem Einsatz von Blueprints können sie auf einer abstrakten Ebene unter Verwendung von abstrakten Notationselementen wie Broker-Server-Verbindungen, persistente Klassen, Patterns oder Framework-Business-Objekten modellieren. Abhängig von der Entwicklungsumgebung und den eingesetzten Klassenbibliotheken können z.B. Assoziationen als Vektoren für die STL-Library oder als Container für MFC etc. abgebildet werden.
Die Singlesource-Technologie bietet somit erstmals einen redundanzfreien Entwicklungsprozeß, beginnend bei der Spezifikation und Analyse, über das Design zur Implementierung und Test des Zielsystems.
Es wird eine permanente Synchronisation und automatische Integrität aller Entwicklungsphasen erreicht.
Uneingeschränktes Roundtrip-Engineering wird damit erstmals möglich.
Abbildung 7: Unterschiedliche Sichten auf den Sourcecode
Die Singlesource-Technologie wird derzeit nur von dem Modellierungswerkzeug Together/Professional unterstützt. Wie der Name together bereits ausdrückt, werden in diesem Werkzeug die Modellierungs- und Realisierungsphasen zusammengebracht. Alle graphischen Modelle werden als Sichten auf den Sourcecode abgebildet. Somit beherrscht dieses Werkzeug Roundtrip-Engineering par excellence.
-
automatische Synchronisierung aller Daten im gesamten Entwicklungsprozesses
-
Uneingeschränktes Roundtrip-Engineering
-
Unterstützung iterativer, inkrementeller Vorgehensmodelle
-
Einfachste Integration aller sourcecodebasierter Entwicklungswerkzeuge
-
Beste Revisionverwaltung und Versionierung über den gesamten Entwicklungsprozeß
-
Abbildung von Spracherweiterungen in graphischen Modellen
Singlesource-Technologie und Repositories sind keine konträre Technologien. Ganz im Gegenteil - die Singlesource-Technologie versucht verschiedene Speicher- oder Abbildungsmechanismen unter einen Hut zu bekommen. Wenn wir es schaffen, die Repräsentationen von abstrakten Analyse-Design-Informationen und die Strukturen des Sourcecodes in einem Topf zu speichern um die notwendigen referenziellen Verbindungen zu unterstützen, dann wird der objektorientierte Entwicklungsprozeß an Qualität und Effizienz gewinnen. Unabhängig vom Speichermedium Datei oder Datenbank.
Dipl. Ing. MBA Frank Sterkmann ist seit 12 Jahren als Managementberater/Projektleiter und seit 2 Jahren als Geschäftsführer bei der Object International Software GmbH in Stuttgart im Bereich der objektorientierten Softwareentwicklung tätig.
