Richtlinie: Mitarbeiter
Ein Mitarbeiter ist eine Abstraktion einer Person, einer Software oder einer Hardware (oder einer Kombination dieser), die im Geschäft agiert. Diese Richtlinie beschreibt, wie Mitarbeiter identifiziert und modelliert werden.
Beziehungen
Hauptbeschreibung

Erläuterung

Ein Mitarbeiter ist eine Abstraktion einer Person, einer Software oder einer Hardware (oder einer Kombination dieser), die im Geschäft agiert. Ein Mitarbeiterobjekt interagiert mit anderen Mitarbeiterobjekten und bearbeitet Geschäftsentitätsobjekte, um eine Geschäftsanwendungsfallinstanz zu realisieren.

Ein Mitarbeiter wird instanziert (im Fall einer Mitarbeiterrolle, die an einen Menschen gebunden ist, "durch eine Person besetzt"), wenn der Workflow der zugehörigen Anwendungsfallinstanz gestartet wird oder spätestens rechtzeitig, so dass das Objekt, das den Job ausführt, seine Rolle in der Realisierung der Anwendungsfallinstanz übernehmen kann. Die Lebensdauer eines Mitarbeiterobjekts (z. B. die Anstellung der Person) entspricht häufig der Ausführungsdauer der Geschäftsanwendungsfallrealisierung.

Wenn Sie sich dazu entschließen, eine Person an eine Mitarbeiterrolle zu binden, erstellen Sie damit auch eine Zuordnung zum RUP-Mitarbeiterblickpunkt (siehe Konzept: Systemarchitektur) und seiner Erweiterung in der Geschäftsmodellierung, der Sicht "Personal" (siehe Konzept: Geschäftsarchitektur). Dieser Punkt ist wichtig, wenn Sie sich Gedanken über die Attribute, Operationen und Merkmale des Mitarbeiters machen, um sicherzustellen, dass diese in der Organisation Unterstützung finden.

Attribute

Ein "menschlicher" Mitarbeiter kann eine Prüfliste haben, an die er sich halten muss. Er kann außerdem Informationen haben, die er den anderen Mitarbeitern oder Geschäftsentitäten zur Verfügung stellt, während er einen Geschäftsanwendungsfall ausführt, z. B. seine Sicherheitsstufe, E-Mail-Adresse usw.

Diese Art von Informationen können implizit in der Beschreibung des Mitarbeiters beschrieben oder explizit als Attribut des Mitarbeiters modelliert werden.

Ein Attribut hat einen bestimmten Typ. Ein Attribut hat einen Namen, vorzugsweise ein Substantiv, das die Rolle des Attributs in Bezug auf die Klasse beschreibt. Ein Attributtyp kann mehr oder weniger primitiv sein, z. B. eine einfache Zahl oder eine Zeichenfolge. Unterschiedliche Klassen können Attribute mit identischen Strukturen haben. Diese Attribute sollten eine gemeinsame Beschreibung haben, d. h. denselben Attributtyp.

Ein Attribut kann mehr oder weniger konkret sein. Sie können beispielsweise die Informationen, die ein bestimmter Mitarbeiter während der Ausführung eines Geschäftsanwendungsfalls berücksichtigen muss, als Attribut modellieren, z. B. charakteristische "verdächtige Verhaltensweisen", die geschulte Zollbeamte im Hinterkopf behalten, um Personen aus dem Strom von Reisenden zur Überprüfung herauszufiltern.

Anmerkung: Sie sollten Attribute nur modellieren, um einen Mitarbeiter verständlicher zu machen!

Operationen

Eine von einem Mitarbeiter bereitgestellte Operation stellt eine bestimmte Aufgabe dar, die von einer Instanz dieser Klasse ausgeführt werden muss. Die Operation eines Mitarbeiters wird durch eine Nachricht von einem anderen Mitarbeiterobjekt oder einem Akteur eingeleitet. Eine Operation hat einen Namen und optional Parameter.

Eine Operation beschreibt eine Aufgabe, die von einem Mitarbeiter angefordert werden kann. Sie wird durch eine Nachricht eingeleitet. Zur Ausführung dieser Rolle in einer Anwendungsfallrealisierung führt ein Mitarbeiter eine oder mehrere Aufgaben aus.

Wenn Sie einen Mitarbeiter entwerfen, d. h. definieren, wozu ein Mitarbeiter in der Lage sein muss, um die gewünschten Ergebnisse eines Geschäftsanwendungsfalls zu liefern, haben Sie zwei Alternativen:

  • Sie können eine allgemeine Beschreibung der Arbeit erstellen.
  • Sie können jede Aufgabe in Form einer Operation explizit definieren. Diese Operation sollte in Textform beschrieben werden. Für jede Operation definieren Sie, welche Nachricht die Ausführung der Operation einleitet.

Jede Operation wird mit einem Namen, der Aufschluss über den Zweck der Operation geben sollte, und optional einer Anzahl von Parametern definiert. Die Parameter geben an, was ein Objekt der Klasse von einem Objekt erwarten sollte, das Unterstützung anfordert oder einen Zugriff vornimmt, und was das Objekt bereitstellt, wenn die Operation ausgeführt wurde. Sie können beispielsweise Parameter angeben, die angeben, wann ein Mitarbeiter einen bestimmen Schritt in der Operation ausführen sollte oder wann dieser Mitarbeiter durch Einleiten einer der Operationen einer Geschäftsentität auf eine bestimmte Geschäftsentität zugreifen sollte. Parameter können auch konkrete Dinge darstellen, die ausgetauscht werden.

Operationen können je nach Bedeutung oder erforderlichem Detaillierungsgrad in einem Anwendungsfall informell oder detailliert definiert werden. Eine "detailliertere" Beschreibung könnte eine Verhaltensfolge beschreiben, die angibt, welche Attribute und Beziehungen während der Ausführung des Anwendungsfalls betroffen sind, wie eine Verbindung zu anderen Objekten anderer Klassen aufgenommen wird und wie ein Anwendungsfall beendet wird.

Merkmale von Mitarbeitern

Die Merkmale eines Mitarbeiters sind eigentlich Vorgaben für die Erfüllung der Rolle. Im Fall eines "menschlichen" Mitarbeiters können Sie sich beispielsweise um Folgendes Gedanken machen:

  • Vorkenntnisse und Erfahrung,
  • physische Merkmale,
  • soziale und physische Umgebung,
  • Job, Aufgaben und Anforderungen,
  • kognitive Merkmale.

Die erfolgreiche Erfüllung der Rolle kann von dem Ausführenden, der diesen Kriterien entspricht, oder davon abhängen, ob er gut in sein Umfeld passt.

Für Softwaresysteme und Systeme im Allgemeinen können Vorgaben formuliert werden, die sich auf die Eignung beziehen, z. B. Leistung, Kapazität, Reaktionsfähigkeit.

Prüfliste für taugliche Mitarbeiter

  • Name und Beschreibung sind klar und verständlich.
  • Jeder Mitarbeiter hat eine Assoziation zu den Geschäftsentitäten, über die er Bescheid wissen muss.
  • Jeder Mitarbeiter hat eine Verbindung zu den anderen Mitarbeitern, mit denen er kommunizieren muss.
  • Die Beziehungen eines Mitarbeiters sind nicht voneinander abhängig.
  • Jeder Mitarbeiter nimmt an mindestens einer Geschäftsanwendungsfallrealisierung teil.
  • Jede Beziehung wird im Workflow mindestens einer Geschäftsanwendungsfallrealisierung verwendet.
  • Jede Operation des Mitarbeiters wird im Workflow mindestens einer Geschäftsanwendungsfallrealisierung ausgeführt.