UML-2.0-Profil für Softwareservices

By Simon Johnston, Architect, IBM Corporation.

Kurzdarstellung

Dieses White Paper beschreibt das Profil für Unified Modeling Language (UML) 2.0, das die Modellierung von Services, serviceorientierten Architekturen und serviceorientierten Lösungen ermöglicht. Das Ziel des Profils besteht darin, eine allgemeine Sprache zur Beschreibung von Services bereitzustellen, die eine Reihe von Aktivitäten im Entwicklungszyklus abdeckt und auch Sichten für verschiedene Stakeholder bereitstellt. Beispielsweise bietet das Profil Funktionen für den Architekten, mit denen Services früh im Lebenszyklus dargestellt werden können. Dazu werden logische Partitionen zur Beschreibung des gesamten unternehmensweiten Service-Portfolios verwendet. Diese Sicht wird von Designern, die die strukturellen und verhaltensbezogenen Servicespezifikationen, die als Verträge zwischen den Serviceclients und den Implementierern fungieren, präzisiert. Die Nachrichtensicht bietet Designern die Möglichkeit, Informationsmodelle für allgemeine Definitionen von Servicedaten wiederzuverwenden.

Das Profil wurde in Rational Software Architect implementiert und erfolgreich für die Entwicklung von Modellen komplexer Kundenszenarios eingesetzt. Es dient auch der Schulung von Personen, die sich mit Problemstellungen bei der Entwicklung serviceorientierter Lösungen befassen.

Übersicht über das UML-Profil für Softwareservices

Konzeptionelles Modell

Das folgende Diagramm ist ein Modell, das die Konzepte, die bei der Modellierung von Services wichtig sind, veranschaulicht. Wie Sie sehen können, gibt es nur relativ wenige Konzepte, die jedem, der schon mit serviceorientierten Lösungen gearbeitet hat, bekannt sein sollten. Beachten Sie jedoch, dass, obwohl das Profil eine Realisierung dieses Modells darstellt, eine Reihe von Konzepten nicht explizite Stereotypen im Profil sind. Beispielsweise gibt es keinen Stereotyp für "Operation" oder "Protokoll", da dies Begriffe sind, die in UML 2.0 existieren und vom Profil eindeutig und ohne weitere Einschränkungen wiederverwendet werden können.

Diagramm ist im Textinhalt beschrieben.

Identifizierte Untergruppe von UML 2.0

In der folgenden Tabelle sind die Elemente des UML-2.0-Metamodells aufgelistet, die als Metaklassen für Stereotype im UML-Profil verwendet werden.

UML-2.0-Metaklasse Stereotypen
Klasse (Class) Nachricht (Message), Servicepartition (Service Partition), Serviceprovider (Service Provider)
Klassifizierungsmerkmal (Classifier) Servicekonsument (Service Consumer)
Kollaboration (Collaboration) Servicekollaboration (Service Collaboration)
Konnektor (Connector) Servicekanal (Service Channel)
Schnittstelle (Interface) Servicespezifikation (Service Specification)
Port Service, Service-Gateway
Eigenschaft (Property) Nachrichtenanhang (Message Attachment)

Das Profil

Das folgende Diagramm, das mit der Maus angeklickt werden kann, veranschaulicht die konkreten Details des Profils mit allen Stereotypen, wobei die Metaklasse die Erweiterungsnotation (ausgefüllte Pfeilspitze) verwendet. Sie können auch einige Einschränkungen im Modell sehen, insbesondere diejenigen, die zwischen Profilelementen bestehen.

Diagramm ist im Textinhalt beschrieben.

Nachricht Servicepartition Serviceprovider Service Service-Gateway Nachrichtenanhang Servicekonsument Servicekollaboration Servicekanal Servicespezifikation

Die folgenden Abschnitte umreißen die Elemente des UML-2.0-Profils laut aktueller Definition. Jeder Abschnitt umreißt einen einzelnen Stereotyp, dessen Details seine Metaklasse, seine Eigenschaften und alle Einschränkungen angeben, die bei der Verwendung des Profils angewendet werden sollen.

Stereotyp 'Nachricht' (Message)

erweitert

Klasse

Semantik

Eine Nachricht repräsentiert das Konzept laut Definition in der WSDL-Spezifikation, d. h. ein Container für tatsächliche Daten, der für den Service und den Konsumenten Sinn ergibt. Eine Nachricht hat möglicherweise keine Operationen, sondern Eigenschaften und Zuordnungen zu anderen Klassen (Klassen eines Domänenmodells). Der Stereotyp "Nachricht" (Message) hat eine Eigenschaft zur Bezeichnung seines angenommenen Codierungsformats (d. h. SOAP-literal, SOAP-rpc, ASN.1 etc.).

Die Verwendung dieses Elements kann in einem Tool aus zwei Gründen optional sein. Erstens möchte der Modellierer vielleicht einfach Elemente aus einem Domänenmodell direkt als Parameter für eine Operation verwenden, anstatt eine Nachricht anzugeben, zweitens möchte er eventuell die Konvention zur Angabe einer Gruppe von Ein- und Ausgabenachrichten für eine Operation verwenden. In diesem Fall müsste das Modellierungstool, wenn es Servicebeschreibungen in WSDL generiert, eine Ein- und Ausgabenachricht erstellen, die mit den Parametern übereinstimmt.

Eigenschaften

Art Name Typ Beschreibung
Eigenschaft encoding String Bezeichnet den Codierungsmechanismus der Plattform, der beim Generieren des Schemas für die Nachricht verwendet werden soll, z. B. SOAP-RPC, Doc-Literal, ASN.1 usw.

Notation

Notation für Nachrichten

Einschränkungen

Stereotyp 'Nachrichtenanhang' (Message Attachment)

erweitert

Eigenschaft

Semantik

Dieser Stereotyp wird verwendet, um anzugeben, dass manche Komponente einer Nachricht ein Anhang ist (im Gegensatz zu einem direkten Bestandteil der Nachricht selbst). Normalerweise wird dieser Stereotyp bei Designaktivitäten der höheren Ebene nicht oft verwendet, aber für viele Prozesse ist es von Bedeutung, angehängte Daten von eingebetteten Nachrichtendaten zu unterscheiden. Beispielsweise kann ein Katalogservice allgemeine Produktdetails als Bestandteil der strukturierten Nachricht zurückgeben, Grafiken werden jedoch als Nachrichtenanhänge zurückgegeben, da die Codierung der Grafiken im Gegensatz zur Textcodierung der Hauptnachricht binär ist.

Eigenschaften

Art Name Typ Beschreibung
Eigenschaft encoding String Bezeichnet den Codierungsmechanismus der Plattform, der beim Generieren des Schemas für die Nachricht verwendet werden soll, z. B. SOAP-RPC, Doc-Literal, ASN.1 usw.

Notation

Notation für Nachrichtenanhänge

Einschränkungen

Stereotyp 'Service'

erweitert

Port

Semantik

Das Servicemodellelement stellt den Endpunkt für die Serviceinteraktion (in der Web-Services-Technologie) bereit, wohingegen die Definitionen dieser Interaktionen Bestandteil der Servicespezifikation sind. Im Modell identifiziert ein Service nicht nur die bereitgestellte Schnittstelle, sondern identifiziert auch erforderliche Schnittstellen (z. B. Callback-Schnittstellen). Ein Service hat eine zusätzliche Eigenschaft, die die zu verwendende Bindung bezeichnet, z. B. SOAP-HTTP, SOAP-JMS usw.

Eigenschaften

Keine.

Notation

Notation für Service

Einschränkungen

Stereotyp 'Servicekanal' (Service Channel)

erweitert

Konnektor

Semantik

Ein Kanal repräsentiert den Kommunikationspfad zwischen zwei Services. Ein wichtiger Punkt ist, dass die Interaktion über einen Kanal erfolgen kann, der Kanal jedoch keine bestimmte Interaktion darstellt. In der Welt der Web-Services bezeichnet jeder Service die Bindungen, die ihm zugeordnet sind (damit ein Client darauf zugreifen kann). In einem Modellierungsprofil können Sie die Bindung entweder hinsichtlich der Kommunikation zwischen Services oder zwischen einem Service und Konsumenten angeben. So können Sie die Bindungsanforderungen flexibel handhaben.

Eigenschaften

Art Name Typ Beschreibung
Eigenschaft Binding String Bezeichnet den Bindungsmechanismus der Plattform, der beim Generieren der Servicebindung in WSDL verwendet werden soll, z. B. SOAP-RPC, SOAP-Doc, HTTP-Get usw.

Notation

Notation für Servicekanal

Einschränkungen

Stereotyp 'Servicekollaboration' (Service Collaboration)

Kollaboration

erweitert

Semantik

Eine Servicekollaboration ist ein Weg, die Implementierung eines Service als Kollaboration anderer Services anzugeben. Aus dem Blickwinkel der Web-Services betrachtet, entspricht das der Verwendung von BPEL4WS bei der Angabe der Serviceimplementierung. Das bedeutet, dass eine Servicekollaboration als Verhalten eines Service verwendet wird und, falls sie in einer Sprache wie BPEL generiert werden soll, möglicherweise weitere implementierungsspezifische Einschränkungen hat.

Eigenschaften

Art Name Typ Beschreibung
Eigenschaft Binding String Bezeichnet den Bindungsmechanismus der Plattform, der beim Generieren der Kollaboration als Prozesschoreographie verwendet werden soll, z. B. "BPEL", "WSFL" usw.

Notation

Notation für Servicekollaboration

Einschränkungen

Stereotyp 'Servicekonsument' (Service Consumer)

Klassifizierungsmerkmal

erweitert

Semantik

Alle Klassifikationsmerkmale (Klasse, Komponente, ...) können als Konsumenten eines Service agieren, und das schließt einen anderen Service ein. Während dieser Stereotyp definitiv optional ist, kann es nützlich sein, die Elemente eines Modells, die selbst keine Services sind, als Clients von Services zu identifizieren. Es kann aber auch sein, dass sie nicht verwendet werden und zusätzlichen Aufwand erzeugen.

Eigenschaften

Keine.

Notation

Notation 'Servicekonsument'

Einschränkungen

Keine.

Stereotyp 'Service-Gateway'

erweitert

Port

Semantik

Ein Service-Gateway erscheint wie ein Service, ist jedoch nur für die Verwendung in Partitionen und nicht Serviceprovidern verfügbar. Ein Gateway agiert als Proxy-Service und kann für die Vermittlung von Protokollen oder die Bezeichnung der für eine Partition verfügbaren Schnittstelle verwendet werden. Beispielsweise ist zu bemerken, dass, obwohl eine Reihe von Services in einer Partition implementiert sind, nur einige für die Verwendung außerhalb der Partition verfügbar sind und daher Gateways für diese Services bereitgestellt werden. Das verstellt anderen Services oder Partitionen die Möglichkeit, mit Services, die nicht über Gateways zugänglich sind, zu kommunizieren.

Eigenschaften

Keine.

Notation

Notation für Service-Gateway

Einschränkungen

Stereotyp 'Servicepartition' (Service Partition)

erweitert

Klasse

Semantik

Eine Partition stellt eine logische oder physische Grenze des Systems dar. Die Modellierung von Partitionen ist zwar optional, aber nützlich. Beispielsweise können Partitionen zur Darstellung der Web-, Geschäfts- und Datenschicht einer traditionellen Anwendung der n-Schicht verwendet werden. Partitionen können auch verwendet werden, um mehr physische Grenzen (z. B. das primäre Rechenzentrum, den sekundären Standort, Kundenstandort, Partner usw.) zu bezeichnen. In diesem Fall kann das Überschreiten von Partitionen bestimmte Einschränkungen hinsichtlich der Sicherheit, der zulässigen Protokolle, der Bandbreite usw. mit sich bringen.

Eine Partition hat möglicherweise nur Eigenschaften, die verschachtelte Abschnitte, seien es Services oder andere Partitionen, darstellen. Beachten Sie, dass das eine Einschränkung ist. Keine anderen Elemente können gegenwärtig in einer Partition dargestellt werden.

Eine Partition kann auch "strikt" sein. Wenn eine Partition vorgibt, dass die gesamte interne Kommunikation und die Kommunikation mit anderen Partitionen durch typisierte Gateways geleitet werden muss, spricht man von einer strikten Partition.

Eigenschaften

Art Name Typ Beschreibung
Eigenschaft Classifier String Ein Klassifikationsname, mit dem der Namespace-Bereich dieser Partition bezeichnet wird.

Notation

Notation 'Servicepartition'

Einschränkungen

Stereotyp 'Serviceprovider' (Service Provider)

erweitert

Klasse

Semantik

Der Serviceprovider ist ein Softwareelement, das einen oder mehrere Services bereitstellt. Was die Modellierung angeht, würde man normalerweise erwarten, an dieser Stelle eine UML-Komponente zu sehen, eine solche Einschränkung erscheint jedoch willkürlich, und so wird die Metaklasse im Interesse einer größeren Flexibilität als Klasse bezeichnet. Ein Serviceprovider hat eine Eigenschaft, die Informationen zu seinem Standort erfasst, obwohl die Bedeutung implementierungsabhängig ist. Die Klasse, die als Serviceprovider agiert, legt möglicherweise keine Attribute oder Operation direkt offen. Möglicherweise werden nur öffentliche Ports bereitgestellt (mit dem Stereotyp "Service"), die von Servicespezifikationen typisiert werden.

Die Eigenschaft "location" ist, wenn implementierungs- und plattformspezifisch, beim Generieren von Serviceendpunktnamen nützlich. Beispielsweise kann der Standort bei Verwendung von WSDL http://svc.myco.com/ sein und ein Service kann den Namen CustInfo haben. In diesem Fall kann der Endpunktname für den Service als http://svc.myco.com/CustInfo generiert werden.

Eigenschaften

Art Name Typ Beschreibung
Eigenschaft allowedBindings String Bezeichnet den Bindungsmechanismus der Plattform, den ein Kanal verwenden kann, wenn er eine Verbindung zum Service herstellt, z. B. SOAP-RPC, SOAP-Doc, HTTP-Get usw.
Eigenschaft location String Der Standort des Providers, der von Generatoren zur Erstellung von Endpunktnamen verwendet werden kann.

Notation

Notation 'Serviceprovider'

Einschränkungen

Stereotyp 'Servicespezifikation' (Service Specification)

erweitert

Schnittstelle

Semantik

Die Verwendung einer Schnittstelle bezeichnet eine Gruppe von Operationen, die von einem Service bereitgestellt werden. Beachten Sie, dass ein Service mehrere Schnittstellen implementieren kann. Laut Konvention ist es möglich, einer solchen Spezifikation eine Protokollzustandsmaschine oder UML-2.0-Kollaboration zuzuordnen, um die Reihenfolge beim Aufrufen von Operationen für eine Servicespezifikation festzulegen. Mit dieser Verhaltensspezifikation können alle Implementierungsservices validiert werden, und zwar nicht nur für eine statische, sondern für eine dynamische Spezifikation ihrer Struktur und ihres Verhaltens. Beachten Sie, dass die Servicespezifikation nur öffentliche Operationen bereitstellen kann.

Eigenschaften

Art Name Typ Beschreibung
Eigenschaft published Boolean Diese Eigenschaft gibt an, ob der Service in einem Service-Repository veröffentlicht werden soll. Sie ist nicht mit der Eigenschaft "public/private" in UML identisch.

Notation

Notation für Servicespezifikation

Einschränkungen

© Copyright IBM Corp. 2005. Alle Rechte vorbehalten.