Hierarchische Dokumentation von Objekten

Worum geht es?
Ein Ereignis nimmt bei der Beschreibung von Programmfunktionalitäten eine Sonderstellung ein. Während z. B. Menüs und Dialoge direkt im Zusammenhang mit der Funktionalität innerhalb eines Programms stehen, beschreibt ein Ereignis Einflüsse, die von außen auf die Anwendung einwirken, um danach eine Reaktion innerhalb dieser Anwendung hervorzurufen. Dies können z. B. Nachrichten sein, die von einem Kommunikationsprogramm an die Anwendung geschickt werden.

Ein Ereignis ist nicht mit der Definition von Ereignis zu verwechseln, wie sie bei der objektorientierten Programmierung verwendet wird. Aus der Sicht eines Programmierers ist es ein Ereignis, wenn eine bestimmte Aktion innerhalb seiner Anwendung ausgeführt wird. Für den, der die Funktionalitäten einer Anwendung beschreibt, ist das nichts anderes als die Auswahl von vorher zur Verfügung gestellten Möglichkeiten.

Auch ist das Ereignis nicht mit Ereignissen zu verwechseln, die von der Anwendung selbst hervorgerufen werden (z. B. während des Speicherns stellt das Programm fest, daß der Speicherplatz erschöpft ist.)

Bei der Beschreibung eines Ereignisses wird nur das Ereignis selber, nicht jedoch die daraus resultierenden Ergebnisse beschrieben. Die aus dem Ereignis folgenden Ergebnisse werden wieder separat Objekten zugeordnet und damit auch separat dokumentiert.

Was bringt es?
Moderne Anwendungen haben immer mehr aktive Schnittstellen, die von außen angesteuert werden. Mit Hilfe von Ereignissen können so alle Möglichkeiten definiert werden, die von außen auf die Anwendung einwirken. Damit besteht die Gelegenheit, alle Schnittstellen zu identifizieren, die einen Automatismus innerhalb der Anwendung in Gang setzen.

Wie wird es gemacht?
Ereignisse setzen immer dann Automatismen innerhalb einer Anwendung in Gang, wenn die Anwendung selbst einen permanent verfügbaren Mechanismus zur Verfügung stellt, der auf das Eintreffen eines Ereignisses wartet.

Dies können z. B. Hintergrundprogramme oder Jobs sein, die Reaktionen innerhalb des Systems hervorrufen. Die nachfolgende Grafik verdeutlicht dies.

Hier wird ersichtlich, daß ein Ereignis niemals losgelößt innerhalb einer Anwendung beschrieben werden kann. Das Ereignis ist immer mit dem überwachenden Mechanismus im Zielsystem verknüpft. Zur Beschreibung dieser Funktionalitäten ergibt sich innerhalb des Pflichtenheftes daraus folgende Hierarchie:

Das Überwachungsprogramm stellt Methoden zur Verfügung, auf bestimmte Ereignisse zu reagieren (1). Tritt das Ereignis ein (1.1), werden Reaktionen (1.1.1) innerhalb der Anwendung erzeugt.

Beispiel 1:

Beispiel 2:

Für die Beschreibung eines Ereignisses sollten Antworten auf folgende Fragen gefunden werden:

• Wie heißt das Ereignis ?
• Wer ist der Auslöser des Ereignisses ?
• Was ist die Quelle des Ereignisses ?
• Wer ist das Ziel des Ereignisses ?
• Welcher Art ist das Ereignis (Datei, Nachricht usw.) ?
• Wie oft wird das Ereignis ausgelöst (Frequenz) ?

Die obige Liste ist als Minimalanforderung zu sehen, die jedes Ereignis als Beschreibung haben sollte. Wenn zusätzliche Erklärungen sinnvoll sind, sollten Sie hier an dieser Stelle gemacht werden. Erläuterungen zum generellen Ablauf sollten jedoch nicht hier niedergelegt werden. Diese Informationen gehören zur Beschreibung des überwachenden Mechanismus. Dort könnte z. B. die grafische Darstellung des generellen Ablaufs der Kommunikation dargestellt werden. Als Visualisierungsmöglichkeit einer solchen Kommunikation bietet sich eine Systematik an, wie sie die oberste Grafik zeigt.

Auslöser	Quelle	Ziel
Art	Häufigkeit
*

• Auslöser
  Hier wird derjenige erfasst, der das Ereignis auslöst. Die kann z. B. ein Mensch sein. Es gibt jedoch auch Ereignisse, die von anderen Systemen z. B. zeitgesteuert angestoßen werden.
• Quelle
  Die Quelle bezeichnet den Ursprung des Ereignisses. Wie genau die Quelle spezifiziert werden muss, hängt von der Anwendung bzw. der Zielgruppe des Pflichtenheftes ab.
• Ziel
  Das Zielsystem, für das das Ereignis bestimmt ist. Hier muss jeweils individuell geprüft werden, wie genau das Ziel beschrieben wird. Die Nennung des Zielsystems alleine kann u. U. nicht ausreichen, wenn das Ereignis z. B. eine Datei ist, die in einem bestimmten Verzeichnis auf dem Zielsystem abgelegt werden muss.
• Art
  Ein Ereignis kann auf unterschiedlichste Arten auf das Zielsystem einwirken. So können Ereignisse z. B. in Form von Nachrichten an das Zielsystem geschickt werden. Sollte die Art des Ereignisses z. B. eine Datei sein, bietet es sich an, diese Datei mit dem Objekt Datei zu beschreiben.
• Häufigkeit
  Die Häufigkeit gibt Aufschluss darüber, ob der überwachende Mechanismus permanent verfügbar sein muss. Sollte z. B. ein Ereignis nur während des Tagesabschluss erwartet werden, muss der überwachende Mechanismus nicht ganztägig verfügbar sein.

Beispiel für die Beschreibung eines Ereignisses: