Aufgabe: Geschäftsanwendungsfallanaylse (SOA)
Diese Aufgabe identifiziert die Designelemente einer serviceorientierten Lösung hinsichtlich der Services und Partitionen und dokumentiert die erste Spezifikation dieser Services.
Zweck
  • Die Designelemente einer serviceorientierten Lösung hinsichtlich der Services und Partitionen identifizieren.
  • Die erste Spezifikation von Services dokumentieren.
  • Die Abhängigkeiten und die Kommunikation zwischen Services bestimmen.
Beziehungen
RollenHauptrollen: Zusätzliche Rollen: Unterstützende Rollen:
EingabenVerbindlich: Optional: Extern:
  • Ohne
Ausgaben
Hauptbeschreibung

Für diese Aufgabe wird das Artefakt Geschäftsanwendungsfallrealisierung als Eingabe verwendet. Ziel dieser Aufgabe ist es, eine Gruppe geeigneter Services zu identifizieren, die in das Serviceportfolio des Projekts aufgenommen werden können. Diese geeigneten Services müssen ggf. noch verfeinert werden. Die hier angegebenen Schritte beschreiben jedoch einen effektiven Weg zur Erstellung einer Ausgangsgruppe von Servicespezifikationen.

Schritte
Geeignete Services anhand von Geschäftsanwendungsfällen identifizieren

Bei der Entwicklung traditionellerer komponentenbasierter und objektorientierter Lösungen werden verschiedene Umwandlungen über mehrere Abstraktionsebenen durchgeführt und Detaillierungsebenen von Anwendungsfällen bis zum Systemdesign hinzugefügt. Das gilt vor allem, wenn ein Geschäftsanwendungsfall als Ausgangspunkt verwendet wird, wie in der Richtlinie Von Geschäftsmodellen zu Systemen dargestellt. Die enthaltene Anleitung erläutert, wie die Entwicklung von Geschäftsmodellen zu Systemen verläuft. Anschließend muss noch ein konkretes Designmodell entwickelt werden.

Bezüglich der Frage, wie ein Servicemodell von einem Geschäftsanwendungsfall abgeleitet werden muss, kann auch eine Parallele zu der Richtlinie, die sich mit der Entwicklung hin zu Systemanwendungsfällen befasst, gezogen werden. Im Allgemeinen wird mit der Erstellung eines geeigneten Service für jede Operation begonnen, die für einen Mitarbeiter im Geschäftsanalysemodell definiert ist. Hier gibt es eine eindeutige Parallele zur Geschäftsprozessanalyse, bei der einzelne Aufgaben in einem Prozessmodell als geeignete Services identifiziert werden.

Im Begleittext beschriebene Abbildung

Diese direktere Verbindung zwischen dem Geschäftsanalysemodell und dem Servicemodell bietet nicht nur den Vorteil, dass sie die Geschäftsanforderungen unterstützt, sondern erfordert auch weniger Umwandlungen zwischen der Formulierung der Geschäftsanforderungen und der Lösung, so dass effektiver auf Änderungen im Geschäftsanwendungsfallmodell oder im Analysemodell reagiert werden kann. Ein weiterer wichtiger Aspekt ist, dass jetzt, da das Geschäftsanwendungsfallmodell auch die Geschäftsziele umfasst, die das Geschäft steuern, die Koordination zwischen Services und Zielen wesentlich einfacher identifiziert werden kann. Beispielsweise ist es jetzt möglich, für jede Servicespezifikation alle Geschäftsziele aufzulisten, zu denen sie beiträgt. Für jedes Geschäftsziel können die tatsächlich in der IT-Abteilung implementierten Services aufgelistet werden, die zum Ziel beitragen. Dazu wird die Verbindung vom Service zur Servicespezifikation verfolgt.

Geeignete Servicespezifikationen weiterentwickeln

In einigen Fällen spiegeln die in der Geschäftsanwendungsfallrealisierung definierten Operationen nicht eine Reihe bestimmter Services wider, sondern eher einen Dialog zwischen den Parteien, die an einem einzelnen Service beteiligt sind. In solchen Fällen können die Operationen (wie unten gezeigt) in einer Servicespezifikation zusammengefasst werden. Dieser Ansatz hat jedoch den Nachteil, dass eine detailliertere Analyse und ein gründlicheres Verständnis der Anwendungsfallrealisierung sowie der Rolle der involvierten Mitarbeiter erforderlich sind, um die Erstellung einer Servicespezifikation als Anforderung zu identifizieren.

Mit "Dialog" sind die für die eigentliche Ausführung eines Service oft erforderlichen zahlreichen Interaktionen zwischen den Parteien gemeint. Wenn Sie beispielsweise den Service PlaceOrder betrachten, werden Sie feststellen, dass er eine Reihe komplexer Interaktionen umfasst, zu denen unter anderem Bestätigungen, Nachrichten zum Versand und Absagen (z. B. bei Nichtverfügbarkeit von Artikeln) gehören können. Schauen Sie sich dazu die folgende Abbildung an.


 

Eigenschaften
Vorgänger
Mehrere Vorkommen
Ereignisgesteuert
Fortlaufend
Optional
Geplant
Wiederholt anwendbar
Weitere Informationen