Fachartikel aus MECHATRONIK 6/2012, S. 42 bis 44
Damit Updates nicht zum Abenteuer werden
OSLC aus Anwenderperspektive
In vielen Unternehmen werden im Verlauf eines Entwicklungsprojektes unterschiedliche Spezialwerkzeuge eingesetzt. Deren Integration über den ganzen Lifecycle hinweg ist nicht immer optimal gelöst. Der typische Ansatz einer engen Punkt-zu-Punkt-Integration zwischen zwei Werkzeugen funktioniert sehr gut, solange es sich wirklich nur um diese beiden Tools handelt. Sobald mehr als zwei Werkzeuge in einem Projekt zum Einsatz kommen, wird die Vermaschung der verschiedenen Integrationen sehr unübersichtlich und jedes Update
eines einzelnen Moduls gerät zum Abenteuer.
 |
| In einer OSLC Umgebung sind nicht die Werkzeuge selbst miteinander integriert, sondern die Daten und Artefakte werden miteinander verknüpft |
Der Weg in Richtung ein Werkzeug für alles – also mit einer Datenbank für alle Aufgaben im Lifecycle – stößt ebenfalls schnell an seine Grenzen. Denn damit werden vorhandene gewachsene Tool-Umgebungen mit den dort gespeicherten Artefakten ausgeschlossen. Eine Migration kann entsprechend sehr aufwendig werden. OSLC (Open Services for Lifecycle Collaboration) zeigt einen dritten Weg auf, der die Nachteile der beiden anderen Ansätze umgeht. OSLC basiert auf Konzepten, die sich im Internet seit Jahren millionenfach bewährt haben. Durch sie können die Tools auf Ressourcen-Ebene integriert werden, wobei gemeinsame Strukturen entstehen. Diese bieten einerseits die gewünschte Basis-Kompatibilität, ermöglichen aber zugleich Erweiterungen für besondere Entwicklungsaufgaben (Bild 1). In OSLC wird jedes Artefakt im Lifecycle als HTTP-Ressource angesehen, die mit den üblichen in der HTTP-Spezifikation vorgesehenen Methoden (GET, PUT, POST, DELETE) manipuliert werden kann. Dabei ist es zunächst unerheblich, um welche Art von Artefakt es sich handelt, zum Beispiel Anforderung, Testfall, Defekt, Quellcode,und so weiter.
Laden Sie sich den vollständigen Beitrag als PDF herunter.
Downloads und Bestellmöglichkeiten