OSLC: Offener Standard für die Tool-Integration

 –  Kommentare

Wie viel effektiver wäre die Entwicklung von Software und Systemen, wenn es im Verlauf eines Projekts nicht so viele Lücken zwischen Teams, Standorten, Tools und Prozessen zu zu überwinden gäbe? Unter dem Oberbegriff Open Services for Lifecycle Collaboration (OSLC) gibt es einen Integrationsansatz zur Sichtung, Bearbeitung und Verknüpfung von Lifecycle-Ressourcen über die Entwicklungswerkzeuge hinaus.

Oft ist schon viel gewonnen, wenn sich die im Projekt eingesetzten Werkzeuge nicht isoliert, sondern integriert nutzen lassen. Ideal wären die Verknüpfung von Artefakten über Werkzeuge und die Zuordnung von Verantwortlichkeiten über Prozesse hinweg, ohne beschwerlichen manuellen Overhead. Die Werkzeuge jedoch, in der Regel organisch gewachsen aus dezidiert eingesetzten und nicht selten von Unternehmen selbst entwickelten Tools für die Lösung spezifischer Aufgaben, bieten meist nur unzureichende Integrationen.

Die Artefakte entlang des Lebenszyklus einer Anwendung, wie Anforderungen, Modelle, Aufgaben, Quellcode oder Testfälle, sollten durchgängig verknüpft und verfolgbar sein, jedoch stehen dafür nur einzelne paarweise Verbindungen zwischen den Werkzeugen zur Verfügung. Hinzu kommt, dass die Daten meist in den Tiefen der Tools vergraben sind und sich nur per spezifischer bilateraler Integration für ein anderes Werkzeug zugänglich machen lassen. Möchte man die Integration funktional erweitern, ist eine neue Anpassung oder Erweiterung des Datenzugriffs erforderlich.

Verständigungsprobleme zwischen den Tools

Dieses eng geknüpfte Netz speziell angepasster Integrationen ist durch alltägliche Ereignisse leicht angreifbar: Schon Upgrades des zugrunde liegenden Betriebssystems oder eine neue Version der Schnittstellenspezifikation können zu Problemen führen. So bieten viele Werkzeuge eine Schnittstelle, mit deren Hilfe Anwender das Werkzeug für spezifische Szenarien anpassen können. Wenn sich nun beim Übergang auf die nächste Version Änderungen an der Schnittstelle ergeben, kann das zur Folge haben, dass die Anpassungen neu zu erstellen sind.

Außerdem nutzen einzelne Tools oft ein eigenes Vokabular, sodass unterschiedliche Begriffe für vergleichbare Dinge verwendet werden oder Werkzeuge denselben Begriff unterschiedlich verstehen. Selbst wenn sich Daten über Werkzeuggrenzen hinweg nutzen lassen, kann es wegen der Bedeutung Missverständnisse geben, oder ein logisches Konstrukt im Entwicklungsprozess kann über mehrere Tools verteilt sein, mit besonderen Anforderungen an die Integration und Synchronisierung zwischen diesen Tools.

Anforderungen an ein Produkt

Ein ideales Produkt würde eine einheitliche Architektur definieren, ebenso wie Protokolle, die die Artefakte aus den unterschiedlichen Werkzeugen in konsistenter Weise integrieren. Würde man das jedoch einem einzelnen Anbieter überlassen, wäre das Resultat nur eine weitere größere "Blackbox", die die Entwicklung weiterer spezifischer Integrationen erfordert. Verwendet man stattdessen offene Standards, die viele Anbieter unterstützen, wird der Nutzen der neuen integrierten Welt die zusätzlichen Kosten der Teilnahme aufwiegen.

Genau die Eigenschaften findet man im Internet, und tatsächlich lässt sich eine solche Integrationsarchitektur dem Internet nachbilden. Charakteristika einer solchen Architektur sind:

  • skalierbar: Es gibt keine Limitierung bezüglich der Anzahl der Anwender beziehungsweise Ressourcen.
  • verteilt: Anwender und Ressourcen können global verteilt sein.
  • zuverlässig: Ein breites Spektrum an Zugriffsprofilen wird zuverlässig unterstützt.
  • erweiterbar: Ressourcen und Protokolle/Dienste sind für zukünftige Erweiterungen vorbereitet.
  • einfach: leicht und flexibel zu erlernen und anzuwenden, eine enge Kooperation und kontinuierliche Koordination zwischen Herstellern ist nicht erforderlich.
  • gleichberechtigt: gleichermaßen zugänglich für alle Teilnehmer, von einzelnen Projekten bis zu großen Anbietern, für Open-Source-, In-house- oder kommerzielle Entwicklung – niemandem wird die Teilnahme verwehrt.

Lifecycle-Integration

Vom Ideal zur praktischen Umsetzung

Wie lässt sich die Internetarchitektur nutzen, um die Zusammenarbeit und gemeinsame Nutzung von Ressourcen über den Anwendungslebenszyklus hinweg zu verbessern? Unter dem Oberbegriff Open Services for Lifecycle Collaboration (OSLC) schlägt IBM einen Lifecycle-Integrationsansatz vor, diese Ressourcen in drei Schritten in "Hyper-Daten" zu transformieren, vergleichbar dem Hypertext-Konzept.

Schritt 1: Internet-URLs für Ressourcen

Der erste Schritt ist, jede Ressource mit einer universellen Adresse zu versehen – egal ob es sich um eine Anforderung, einen Testfall, eine Fehlerbeschreibung oder etwas anderes handelt. Ähnlich wie URLs als globale Adressen von Webseiten fungieren, werden bei OSLC URLs als Adresse für jede einzelne Ressource verwendet. Über ihre URL lässt sich die Ressource von jeder Webseite, jedem Werkzeug oder jeder anderen Lifecycle-Ressource ansprechen.

Schritt 2: Gemeinsamkeiten der Ressourcenformate

Der erste Schritt wies auf den Weg hin, jede Ressource mit einer Adresse zu versehen. Das liefert jedoch noch keine Information über den Inhalt, was keine Restriktion, sondern einen Vorteil der flexiblen Architektur bedeutet. Ressourcen sind nicht beschränkt auf eine vordefinierte Typauswahl. Eine Anforderung beispielsweise lässt sich als ein Textdokument (Beschreibung), ein Bild (optische Darstellung) oder ein XML-Dokument (Definition der Attribute) repräsentieren. Ein Werkzeug, das die Beziehung zwischen einem Testfall und einer Anforderung überwacht, muss nicht den Inhalt der Anforderung verstehen; es reicht das Wissen um ihre Existenz und wo sie steht. Wenn der Anwender den Inhalt der Anforderung sehen möchte, funktioniert das Tool wie ein Browser, der die Ressource nimmt und an eine geeignete Funktion zur Visualisierung übergibt.

Diese Flexibilität ist zwar hilfreich, noch mehr lässt sich mit den Ressourcen anfangen, wenn man einige Details über das Format weiß. Daher schlägt IBM vor, im zweiten Schritt Lifecycle-Ressourcen in XML zu definieren und gemeinsame Elemente zu benutzen. Damit ist die Ressource nicht mehr eine Blackbox, sondern wird semitransparent, und jedes Werkzeug kann die gemeinsamen Elemente begutachten. Zusätzlich zu den gemeinsamen Elementen kann ein Tool die Ressource mit weiteren "privaten" Elementen ausstatten, um werkzeugspezifische Informationen abzuspeichern.

Ein wesentlicher Vorteil dieses mit dem Internet ähnlichen Ansatzes liegt darin, dass Werkzeuge Ressourcen gemeinsam nutzen können, ohne eng integriert zu sein. Die Tools müssen nur die gemeinsamen inhaltlichen Elemente vereinbaren; Format, Inhalt oder Bedeutung der privaten Elemente lassen sich beliebig ändern. Selbst wenn sich ein Einvernehmen über alle gemeinsamen Elemente erzielen lässt, ist das kein Hinderungsgrund für die Zusammenarbeit. XML ermöglicht, dass ein Tool Elemente ignoriert, die für es unverständlich oder ohne Belang sind. Dank dieser Eigenschaft sind die Werkzeuge daher tolerant gegenüber nicht vollständiger Kompatibilität der gemeinsamen Daten – im Gegensatz zum traditionellen Verfahren, bei dem geringfügige Abweichungen zu ernsthaften Fehlern führen können.

Gemeinsame Elemente ermöglichen Werkzeugen, Ressourcen anzulegen, anzuschauen und in ein lokales Format zu übertragen. Für eine engere Zusammenarbeit sind indes weitere Design-Richtlinien erforderlich, damit beispielsweise ein Tool eine Ressource ändern kann, die es nicht selbst angelegt hat. Das ist erforderlich, damit Werkzeuge zusätzliche Informationen in Ressourcen speichern können oder für das Herstellen von Querbezügen zu anderen Ressourcen. Beispielsweise könnte ein Business-Analyst, der mit einem traditionellen Werkzeug für das Requirements Management arbeitet, einige Anforderungen als Use Cases dokumentieren. Ein Designer, der ein UML-Modellierungswerkzeug verwendet, könnte sie ergänzen, ohne dass die Werkzeuge eng integriert sein müssen und ohne formalen Sprung zwischen "Anforderungsphase" und "Designphase", wie viele heutige Integrationen es vorsehen.

Schritt 3: Gemeinsame Services

In Ergänzung der gemeinsamen Ressourcenformate sind nun geeignete Interfaces von Nöten, um Dienste (Services) der Ressourcen zugänglich zu machen. Das Konzept von RESTful-Webservices dient hier als Inspiration für die Implementierung. Ein Designer, ausgerüstet mit seinem UML-Tool, könnte beispielsweise feststellen, dass weitere Anforderungen in Form von Use Cases definiert werden sollten. Er würde die Anforderungen gern erzeugen und sie in den Freigabeprozess des Anforderungsmanagementwerkzeugs einfließen lassen. Mit einer REST-Architektur reicht es, wenn das UML-Tool weiß, wo neue Anforderungen abzulegen sind, um den Prozess anzustoßen. Das UML-Tool muss nicht speziell an das Anforderungsmanagementwerkzeug angepasst sein oder dessen spezifische APIs oder Terminologie kennen. Auf der Basis lassen sich weitere Dienste anbieten, etwa für gemeinsame Abfrage und Reporting, Traceability-Analyse und durchgängige Prozessunterstützung.

Jeder Schritt eröffnet bessere Optionen für die Integration. Für individuelle Werkzeuge können zusätzlich oder speziell angepasste Schritte empfehlenswert sein. Der Aufgabenbereich der Open Services for Lifecycle Collaboration ist absichtlich begrenzt auf einige wesentliche Bausteine, von denen Anwender und Anbieter von Werkzeugen gleichermaßen profitieren sollen. OSLC soll nicht das gesamte Universum der Integrationen von Lifecycle-Werkzeugen ersetzen oder einschränken.

Die Schritte lassen sich sowohl auf bestehende als auch auf neue Tools anwenden. Wesentliches Designelement ist die Wahl eines Integrationsmechanismus, der vorhandene Ressourcen erweitern kann, analog der Art und Weise, wie Webservices existierende Dienste ummanteln können, unabhängig von der Implementierung.

Fazit

Über die jeweilige Domäne eines Werkzeugs hinaus

Erfahrungen mit den Herausforderungen der Kunden und die Arbeit an der Jazz-Plattform haben IBM zu dem Ansatz geführt. Inzwischen verwendet ihn das Unternehmen für die Entwicklung neuer Produkte, damit Business Analysten, Programmierer und Tester über ihre Tools hinweg zusammenarbeiten können, etwa bei der Collaborative-ALM-Initiative.

(Bild: oslc.net)

Das Ziel von OSLC ist die Schaffung einer offenen einheitlichen Methode, um Lifecycle-Ressourcen über die Tools hinaus zu sichten, zu bearbeiten und zu verknüpfen. Mehrere Arbeitsgruppen arbeiten an spezifischen Themen, zurzeit zählen dazu Änderungsmanagement, Anforderungsmanagement, Testen und PLM (Product Lifecycle Management). Weitere Schwerpunkte sind unter anderem die Erweiterung der Reporting-Spezifikationen sowie Automatisierung und Inbetriebnahme. Jede OSLC-Arbeitsgruppe arbeitet an Revisionen basierend auf dem Feedback der Community. In ihnen engagieren sich Experten mit Erfahrungen in klassischen IT-Anwendungen und im Systems Engineering. Beteiligt sind unter anderem Unternehmen wie Black Duck, Boeing, Citigroup, EADS, General Motors, Oracle, Shell, Siemens, Sogeti und Tasktop.

Der Fortschritt der einzelnen Arbeitsgruppen und viele andere Informationen sind auf open-services.net nachzulesen.

Fazit

Mit wachsender Vielfalt der im Verlauf des Anwendungslebenszyklus eingesetzten Werkzeuge gibt es zunehmenden Bedarf nach einer Integration der Tools. Der typische Ansatz der engen Punkt-zu-Punkt-Integration zwischen zwei Werkzeugen funktioniert gut, solange es sich nur um genau diese beiden Tools handelt, die in einem Projekt eingesetzt werden. Sobald man mehrere einsetzt, wird die Vermaschung der bilateralen Integrationen unübersichtlich und jedes Modul-Update gerät zum Abenteuer.

Der Weg in Richtung "one for all", eines Werkzeugs mit einer Datenbank für alle Aufgaben im Lifecycle, stößt ebenfalls schnell an seine Grenzen, weil man damit das Vorhandensein gewachsener Tool-Umgebungen mit den dort gespeicherten wertvollen Artefakten ignoriert.

OSLC zeigt einen dritten Weg auf, der die Nachteile der beiden anderen Ansätze umgehen soll: Durch das Nutzen von Konzepten, die sich im Internet bewährt haben, lassen sich die Tools auf Ressourcenebene integrieren, und es entstehen gemeinsame Strukturen. Diese bieten einerseits die gewünschte Basis-Kompatibilität, ermöglichen aber zugleich Erweiterungen für besondere Entwicklungsaufgaben. Aufwendungen für die enge Integration von Werkzeugen fallen nicht mehr an, weder auf Herstellerseite für die Implementierung und Wartung noch auf Anwenderseite für den kontinuierlichen Betrieb. Die Einbindung schon installierter Tools in das Konzept sichert Investitionsschutz, die im Konzept angelegte Erweiterbarkeit wiederum den Ertrag heutiger Investitionen für die Zukunft.

Dass nicht allein IBM in der OSLC-Community sich um eine Weiterentwicklung bemüht, mag eine breite Abdeckung unterschiedlicher Anforderungen durch dieses Konzept gewährleisten. Erst kürzlich wurde das Eclipse-Projekt Lyo gestartet mit dem Ziel, Softwareentwicklungs-Kits für Werkzeughersteller zu erstellen. Diese sollen die Implementierung der OSLC-Spezifikationen vereinfachen und so zu einer breiteren Akzeptanz beitragen. (ane)

Renate Stücka
ist Senior Market Manager für Nordosteuropa des Rational-Bereichs der IBM Software Group.