RoSE: Requirements-oriented Service-Engineering (Teil 2) – RE für Services

In Teil 1 unserer Blogserie hatten wir uns mit der Frage beschäftigt, was sich hinter dem Begriff SOA verbirgt. Dabei haben wir festgestellt, dass es sich bei SOA um ein Architekturparadigma handelt, das durch die Anwendung der Prinzipien der Service-Orientierung entsteht. Weiter haben wir zwei grundlegende Sichten auf die SOA und den Service identifiziert und diese kurz beschrieben.

In diesem Blogbeitrag wollen wir im Rahmen einer Kontextabgrenzung eingrenzen, was wir in unserem Innovations-Projekt genauer betrachten und anschließend das eingegrenzte Thema kurz vorstellen.

Betrachtet man SOA auf geschäftlicher und technischer Ebene, so ergeben sich für jede der beiden Perspektiven zahlreiche Themengebiete. So lassen sich zur geschäftlichen SOA Themen wie z.B. Geschäftsprozessmanagement und -modellierung, SOA-Governance oder die Einführung von SOA in einer Organisation zuordnen. Demgegenüber steht die technische SOA, zu der sich Themen wie die Implementierung von SOA-Komponenten wie dem Service-Bus oder die Realisierung von Service mittels Webservices zuordnen lassen. Angesichts des Umfangs und der Tiefe der einzelnen Themen wurde der Fokus in diesem Innovationsprojekt auf die zentrale Entität der SOA, den Service, gelegt und diesbezüglich die Methoden und Techniken des RE untersucht.

Ein Service durchläuft in einer SOA einen Lebenszyklus, der im Groben die Phasen Identifizierung, Design, Implementierung, Test, Integration, Betrieb und Außerbetriebnahme umfasst. Dabei wird der Service in der ersten Phase anhand z.B. bestehender Services bzw. Geschäftsprozessmodelle identifiziert. Steht fest, welcher Service entwickelt werden soll, so wird in den folgenden drei Phasen analog zu den typischen Phasen der Software-Entwicklung zunächst das Design entworfen, anschließend der Service implementiert und schließlich getestet. Typisch für Services in einer SOA ist das Betreiben, denn Services stellen Dienstleistungen dar und unterliegen der Wartung und Pflege wenn sie erst einmal in Betrieb genommen wurden. Wird ein Service nicht mehr benötigt, so wird er aus dem laufenden Betrieb entfernt. Hierfür ist eine umfassende Prüfung der Auswirkungen notwendig, damit sichergestellt wird, dass es zu keinen unerwünschten Effekten kommt, wenn z.B. noch jemand den Service nutzt und dieser ihm buchstäblich unter den Füßen weggezogen wird. Diese Phasen sollten selbstverständlich nicht sequenziell durchlaufen werden, sondern stellen lediglich die einzelnen Stationen im Lebenszyklus eines Service dar, da z.B. bei Änderungen des Designs auch die Implementierung angepasst werden muss (Josuttis, 2008).

Betrachtet man diesen Lebenszyklus aus Sicht des RE, so ist die Phase der Identifizierung von Services für uns von besonderer Bedeutung und wird daher fokussiert betrachtet. Dabei wurden die Aktivitäten bei der Systemanalyse (Rupp, 2009) herangezogen und davon ausgehend folgende Tätigkeiten bei der Analyse von Services identifiziert:

RE u. SOA_Teil 2_Bild 1_Tätigkeiten_bei_der_Analyse_von_Services
Abbildung 1: Tätigkeiten bei der Analyse von ServicesGrundsätzlich sollten analog zur Systemanalyse auch bei der Analyse eines Service verschiedene vorbereitende Tätigkeiten durchgeführt werden, bevor die eigentliche Analyse des Service in Angriff genommen werden kann.

In Abbildung 1 sind diese Tätigkeiten das Identifizieren der Stakeholder, das Festlegen der Ziele die durch den Service erfüllt werden sollen und das gemeinsame Abgrenzen des Kontextes. Da diese Tätigkeiten nicht zwangsweise sequenziell durchgeführt werden müssen und es auch beispielsweise bei der groben Analyse des Service noch Auswirkungen auf die Kontextabgrenzung geben kann, wurden zur Veranschaulichung der Tätigkeiten in obiger Abbildung Anwendungsfälle verwendet. Sind die Ziele und der Kontext des Service bekannt, so kann mit der groben Analyse des Service begonnen werden. Bei der groben Analyse wird sich mit der Frage beschäftigt, ob für die ermittelten Anforderungen ein bestehender Service verwendet werden kann. In diesem Fall kann eine Nutzungsvereinbarung geschlossen werden. Kann keiner der bestehenden Services für die Anforderungen herangezogen werden, so sind weitere Analysen notwendig. Da wir den Hauptfokus auf die technische Sicht des Service legen, werden die Anforderungen an den technischen Service auch in einem möglichen Folgeschritt verfeinert, falls dies notwendig ist. Im Laufe der Analyse des Service ist auch erforderlich die ermittelten Anforderungen an den Service geeignet zu strukturieren und zu verwalten, um sie für weitere Arbeiten zur Verfügung zu stellen. Während der Analyse des Service wird man mit den unterschiedlichsten Begriffen konfrontiert, diese müssen jedoch im Laufe der Analyse durch Verwendung von z.B. einem Glossar oder einem Begriffsmodell vereinheitlicht werden, um ein gemeinsames Vokabular festzulegen.

In den folgenden Beiträgen sehen wir uns den Anwendungsfall Service grob analysieren genauer an und legen auch dabei wieder den Fokus auf die technischen Services. Hierfür muss aber zunächst geklärt werden, welche Anforderungen und Anforderungsarten es für technische Services geben kann.

Das erfahren Sie in Teil 3 der Blogserie ROSE!

Ihre SOPHISTen.

————————————————–

Teil 1: RoSE: Requirements-oriented Service-Engineering – Was ist SOA?  
Teil 3: RoSE: Requirements-oriented Service-Engineering  – Anforderungen und Services 
Teil 4: RoSE: Requirements-oriented Service-Engineering  – Anforderungen an Services ermitteln 

————————————————–

Literaturverzeichnis

Josuttis, Nicolai. 2008. SOA in der Praxis. 2008. S. 169-177, dpunkt, ISBN-13: 978-3898644761

Rupp, Chris. 2009. Requirements-Engineering und -Management. s.l. : Carl Hanser Verlag, 2009, ISBN-13: 978-3446418417

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *


− zwei = 3

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>