Konzept: Deskriptor
Ein Deskriptor ist ein Prozesselement, das die Verwendung oder Anwendung eines Methodeninhaltselements im Prozess darstellt. Der Deskriptor gibt Ihnen die Möglichkeit, das, was im ursprünglichen Methodeninhaltselement definiert ist, zu überschreiben bzw. diesem etwas hinzuzufügen. Zu den Deskriptoren gehören Rollen-, Aufgaben- und Arbeitsergebnisdeskriptoren.
Hauptbeschreibung

Ein Deskriptor stellt ein Vorkommen eines konkreten Inhaltselements (z. B. eine Aufgabe, eine Rolle oder ein Arbeitsergebnis) in einer Aktivität dar. Deskriptoren liefern eine Proxy-ähnliche Darstellung dieser Inhaltselemente innerhalb von Gliederungsstrukturen. Sie verweisen nicht nur auf Inhaltselemente, sondern ermöglichen auch, die strukturellen Beziehungen von Inhaltselementen durch Festlegung eigener Assoziationen zu überschreiben.

Deskriptoren sind ein wichtiges Konzept für die Abgrenzung von Prozessen und Methodeninhalt. Ein Deskriptor kann als Referenzobjekt für ein bestimmtes Inhaltselement bezeichnet werden, das eigene Beziehungen und Eigenschaften hat. Wenn ein Deskriptor erstellt wird, hat er dieselben Beziehungen wie das referenzierte Inhaltselement. Der Benutzer kann diese Beziehungen für die jeweilige Prozesssituation, für die der Deskriptor erstellt wird, jedoch ändern. Das Deskriptorkonzept ermöglicht die Definition neuer Beziehungen und spezifischer prozessbezogener Eigenschaften. Deskriptoren sind keine Inhaltselemente und enthalten auch nicht deren vollständige Beschreibungen. Vielmehr verweisen Sie auf die Inhaltselemente, auf denen sie basieren.

Beispiel

Beispiel für einen von einem Deskriptor referenzierten Methodeninhalt

Beispiel für einen von einem Deskriptor referenzierten Methodeninhalt


Die vorherige Abbildung zeigt ein Beispiel, in dem die UML-2.0-Profildarstellung für UMA verwendet wird und in dem Deskriptoren für eine Aufgabe, die ausführenden Rollen sowie die zugehörigen Ein-/Ausgabearbeitsergebnisse erstellt wurden. Die dargestellte Situation impliziert, dass die Aufgabe "Prioritäten für Anwendungsfälle vergeben" in der Konzeptionsphase eines Projekts anders ausgeführt werden muss als in der Ausarbeitungsphase (d. h. mit unterschiedlicher Gewichtung verschiedener Schritte, Verwendung anderer Eingaben usw.). Es kann Folgendes beobachtet werden:

  • Die Aufgabe hat in der Konzeptionsphase eine zusätzliche unterstützende Rolle (Kunde.Projektleiter) und keine Beziehung zum Arbeitsergebnis Liste der Risiken, das als optionale Eingabe im Methodeninhalt definiert ist (d. h. Schritte in der Aufgabe, die mit der Liste der Risiken arbeiten, werden in dieser Phase ausgelassen).
  • Es wird hier zwischen zwei verschiedenen Typen von Arbeitsergebnissen Anwendungsfallmodell unterschieden: Einem Anwendungsfallmodell, wie es normalerweise in der Konstruktionsphase verwendet wird und das Anwendungsfälle nur kurz beschreibt, und Anwendungsfällen, die wie in der Ausarbeitungsphase üblich detailliert beschrieben sind.