Der Begriff der Entität wird in der Informatik vielfältig genutzt. In der Regel wird er verwendet, um selbständige Operanden, an denen bestimmte Operationen ausgeführt werden können, zu beschreiben. Die Beziehungen zwischen Entitäten reichen von relativ starren Verbindungen (z.B. in Datenbanken) über dynamische Verbindungen wie in der CAMARS-Technologie bis hin zur absoluten Unabhängigkeit und der Kommunikation über vordefinierte Einheiten (DEMONs) in heterarchischen Systemen (SINGH pp.4350-4353: Simulation Modelling Formalism: Heterarchical Systems). In letzteren werden Entitäten als Individuen definiert, die sich selbst genügen. Sie verfolgen ihre eigenen Ziele, besitzen eigene Informationen und können mit Unterstützung der DEMONs selbständig Beziehungen zu anderen Individuen aufbauen. Diese Definition der Entität scheint noch am ehesten zu verdeutlichen, worin ihr Wesen besteht. In ereignisorientierten Simulationsmodellen wird der Begriff der Entität dem Begriff der Ereignisses gegenübergestellt. Hier stellen Entitäten die Simulationsobjekte (temporär oder permanent) dar, auf die die Ereignisse einwirken (SINGH pp.4346-4348: Simulation Modelling Formalism, Event-Based).
Wir wollen den Entitätsbegriff so verwenden, wie er im Abschnitt 3.1. eingeführt wurde:
Entitäten sind ihrem Wesen nach Operanden. Durch die eindeutige Zuordnung von Zustandsgraphen zu ihnen repräsentieren sie gleichzeitig die an ihnen auszuführenden Steuerungsprozesse. Insofern können Entitäten auch als Prozesse aufgefaßt werden. Diese Dualität von Operand und Prozeß ist eine der wichtigsten Eigenschaften der Entitäten.
Durch die Gesamtheit der Entitäten wird das Modell der Basis in der Steuerung beschrieben. Dazu gehören neben den aktuellen Zuständen der Basiselemente auch deren gegenseitige Beziehungen, die durch die Basisanalyse gewonnen wurden. Auf der Grundlage dieses Modells kann der Steuerungsprozeß den ihm zugeordneten Basisprozeß steuern.
Da Entitäten Operanden des Steuerungsprozesses sind, bewirkt dessen Ausführung Zustandsänderungen der Entitäten. Andererseits entsprechen den Entitäten bestimmte Elemente der Basis, so daß jede Zustandsänderung einer Entität eine Zustandsänderung in der Basis widerspiegeln muß.
Zwischen den Elementen der Basis bestehen gewisse Beziehungen (s. Basisanalyse). Diese widerspiegeln sich in Wechselwirkungen zwischen Entitäten derart, daß Transitionen einer Entität Transitionen bei einer anderen Entität auslösen können. Diese Wechselwirkungen stellen Nachrichten dar. Wir können damit neben den Zustandsgraphen eine Struktur auf Entitäten angeben. Diese ist ihrem Wesen nach eine operandenbewertete Prozeßstruktur, in der die Operanden Nachrichten sind. Diese Entitätsstrukturen sind teilweise aus dem Ergebnis der Basisanalyse ableitbar. Sie müssen aber auch die Aufgaben der Steuerung berücksichtigen.
Der Unterschied zu den Steuerungsprozeßstrukturen, die durch horizontale Dekomposition des Steuerungsprozesses gewonnen werden können (ENGELIEN/STAHN 1984), besteht darin, daß in Entitätsstrukturen keine Entitäten als Kantenbewertung vorkommen. Im Gegenteil, die Entitäten stellen sowohl in ihrer Eigenschaft als Operand als auch als Prozeß der Steuerung die Trägermenge dieser Struktur dar. Die Prozesse, die durch horizontale Dekomposition eines Steuerungsprozesses entstehen, können den Entitäten eindeutig zugeordnet werden.
Ähnliche Strukturen finden wir auch in Modellen der objektorientierten Programmierung wieder. Hier werden die Entitäten als Objekte bezeichnet, die über diesen ausführbaren Operationen werden definiert und es wird eine Schnittstelle der Objekte zu ihrer Umgebung festgelegt. Die Kommunikation mit anderen Objekten vollzieht sich über diese Schnittstelle, die Funktionsaufrufe oder Nachrichtensendungen enthalten kann (vgl. KÜHLE). Diese Strukturen sind ihrem Wesen nach Operandenstrukturen. Da in der objektorientierten Programmierung der Zustandsbegriff nicht oder kaum verwendet wird, können diese Strukturen auf Objekten nicht wie Prozeßstrukturen entworfen und hantiert werden. Dazu wäre es notwendig, den Objekten explizit Zustände und Zustandsgraphen zuzuordnen.
Das Actor-Modell (MATTERN) des MIT arbeitet ebenfalls mit derartigen Strukturen (Bekanntschaft der Actoren; Acquaintance). Hier werden aber Asymmetrie und Nichttransitivität gefordert, die für unsere Entitätsstrukturen nicht notwendig sind. Weder in der objektorientierten Programmierung noch im Actor-Modell finden wir eine Trennung von Basis und Steuerung, so daß beide Modelle, auf den Entwurf von Steuerungen angewandt, erst in der Phase des Implementationsentwurfs zum Tragen kommen könnten. Wir können von einer bestimmten Stelle des Software-Entwurfs an die Mittel und Methoden dieser Modelle für unsere Ziele verwenden (WUNSCH 1989). Dabei dürfen wir aber nicht die bisher erkannten Mittel und Methoden der Implementationsvorbereitung aus den Augen verlieren.
Ein Steuerungsprozeß kann also hinreichend durch seine Entitätsstruktur und die Zustandsgraphen seiner Entitäten beschrieben werden.
Eine immer wieder auftretende Frage ist die nach den Bedingungen, unter denen ein Basiselement zur Entität wird. Diese Frage ist nicht einfach zu beantworten. Voraussetzung ist eine hinreichend genaue Analyse der Basis und der Aufgaben der Steuerung. Wird die Basis als universell betrachtet, d.h., kann sie alle gestellten Aufgaben ohne Einschränkungen lösen, so besteht die Aufgabe des Steuerungsprozesses lediglich darin, die von der Umgebung erhaltenen Informationen an den Basisprozeß und umgekehrt weiterzuleiten. In diesem Fall gibt es in der Steuerung keine Operanden, denen Elemente der Basis zugeordnet sind. Die Steuerung einer universellen Basis enthält demnach keine Entitäten.
Deshalb kann davon ausgegangen werden, daß Basisprozeßelemente stets Entitäten werden. Für diese können nun Zustandsgraphen angegeben werden.
existent ---> operend ---> beendet
Diese drei Zustände sind für einen Basisprozeß mindestens wesentlich. 'Existent' heißt ein Basisprozeß dann, wenn er noch ausgeführt werden muß, 'operend', wenn er sich in der Ausführung befindet und 'beendet', wenn er ausgeführt worden ist.
Dabei bewirkt ein Zustandsübergang von 'operend' nach 'beendet' eine Nachricht an alle direkten Nachfolgeroperationen, die nun einen Zustandsübergang von 'existent' nach 'operend' ausführen könnten. Diese Transition wird aber nur ausgeführt, wenn alle Vorgängeroperationen eine Nachricht über ihre Beendigung geschickt haben. In diesem Fall wird an einen untergeordneten Steuerungsprozeß eine Weisung zur Ausführung der Operation gesendet. Wird von der untergeordneten Steuerung die Meldung empfangen, daß die Operation ausgeführt wurde, kann die Transition von 'operend' nach 'beendet' ausgeführt werden mit allen oben beschriebenen Wirkungen.
Beschreibt nun aber dieser Zustandsgraph die Steuerung hinreichend genau? Jedem Basisprozeß ist doch mindestens ein Operator zugeordnet, wird dieser nicht auch zur Entität?
Wir haben festgestellt, daß jedem Basisprozeß ein Steuerungsprozeß zugeordnet ist. Diese Zuordnung könnte fest vorgegeben sein oder bei der Ausführung der Transition von 'existent' nach 'operend' festgelegt werden. Wenn dieser Steuerungsprozeß jederzeit in der Lage ist, Anweisungen zu empfangen, dann braucht der Operator nicht berücksichtigt zu werden.
Dennoch ist ein weiteres Basiselement für die Steuerung von Bedeutung: die übergeordnete Prozeßeinheit, der Auftrag. Sein Zustandsgraph besteht aus zwei Zuständen, 'in Arbeit' und 'erledigt'.
in Arbeit ---> erledigt
Die Transition wird dann ausgeführt, wenn alle zugeordneten Operationen 'beendet' sind. Das heißt natürlich, daß jede Operation bei ihrer Beendigung auch den Auftrag, zu dem sie gehört, benachrichtigen muß. Die Ausführung der Transition bewirkt eine Endemeldung an den Steuerungsprozeß, der den Auftrag angewiesen hat.
Wenn ein Auftrag angewiesen wird, befindet er sich initial im Zustand 'in Arbeit'. Doch es ist auch noch notwendig, alle zu diesem Auftrag gehörenden Operationen zu erzeugen. Hier ist es vorteilhaft, für eine einheitliche Beschreibung aller auszuführenden Steuerungsprozesse den Zustand 'vor Erzeugung' in den Zustandsraum des Auftrages aufzunehmen. Damit löst eine Weisung eine Transition von 'vor Erzeugung' nach 'in Arbeit' aus, die der Initialisierung des Auftrages entspricht. Zusätzlich enthält die Aktion die Erzeugung aller Operationen des Auftrages incl. ihrer Verkettung. Eine Aufnahme des Zustandes 'vor Erzeugung' in den Zustandsraum der Operationen ist nicht unbedingt notwendig, da durch eine entsprechende Transition in diesem Zustandsgraphen weder Zustandsänderungen noch Ausgaben bewirkt werden.
Im Prinzip kann jedes Basiselement eine Entität der Steuerung werden. Wann und warum wird ein Basiselement nicht Entität?
Hinweis: In jeder Dokumentation sollte ausführlich begründet werden, warum eine Klasse von Basiselementen nicht als Entität behandelt wird, da durch eine veränderte Aufgabenstellung u.U. die Behandlung dieser Elementklasse als Entität notwendig wird. Eine solche Dokumentation bietet außerdem den Vorteil, ggf. notwendig werdende Zustandsgraphen schnell zu entwickeln oder auch bei Änderungen eine leichte Überprüfung vornehmen zu können, ob ein Element als Entität behandelt werden muß oder nicht.
Die Begründung für die Hantierung einer Elementeklasse als Entität erscheint angesichts dessen als weniger wichtig, da sie schon in der Basisanalyse enthalten ist.
Die an den Entitäten auszuführenden Prozesse können durch Zustandsgraphen beschrieben werden. Diese Zustandsgraphen stellen die in der Basis auszuführenden Prozesse dar, die wesentlich für die Steuerung sind. Daraus ergeben sich die Anforderungen an die Zustandsgraphen der Entitäten:
Der Entwurf der Zustandsgraphen für Entitäten ist ein komplizierter Prozeß. Der erste Schritt besteht darin, alle einer Entität zugeordneten Informationen zu ermitteln. Diese können klassifiziert werden in Zustandsmerkmale und Verkettungsinformationen. Zustandsmerkmale unterscheiden sich wiederum in solche mit kleinem und solche mit großem oder unendlichem Zustandsraum. Ist diese Zuordnung abgeschlossen, kann mit dem Entwurf der Zustandsgraphen begonnen werden. Dabei zeigt sich häufig, wie auch bei anderen Entwurfsverfahren, daß unter Umständen in vorhergehenden Entwurfsschritten Änderungen oder Ergänzungen vorgenommen werden müssen.
Der Entwurf der Zustandsgraphen muß für jedes Zustandsmerkmal mit kleinem Zustandsraum erfolgen. Die Transitionen in Zustandsgraphen mit großem oder unendlichem Zustandsraum können entweder in andere Zustandsgraphen aufgenommen werden oder durch folgenden Zustandsgraphen realisiert werden.
___________
| |<-----+ x: Aktivierungsbedingung
| Zustand z | | y: Berechnung des Folge-
|___________|------+ zustands
Realisierung großer oder unendlicher Zustandsgraphen
Beim Zustandsgraphen-Entwurf ist darauf zu achten, nur die logischen Zusammenhänge in den Zuständen und Transitionen darzustellen. Zu häufig wird der Entwurf an der späteren Implementation orientiert. Das erschwert erheblich das Verständnis für die Entwurfsergebnisse und beeinflußt sogar die Portabilität des Software-Produktes. Eine Implementationsabhängigkeit des Entwurfs wird u.a. an folgenden Merkmalen sichtbar:
Im logischen Entwurf der Zustandsgraphen müssen die in der Entitätsstruktur angegebenen Beziehungen zum Ausdruck kommen. Somit widerspiegelt die Entitätsstruktur die Kooperation von Zustandsgraphen. Die Bedingungen, die zu Transitionen führen, werden in Abhängigkeit der eingehenden Nachrichten und anderer interner Zustände formuliert. Ebenso ist die Prüfung von Zuständen anderer Entitäten möglich. Die durch Transitionen ausgelösten Aktionen beinhalten die Änderung interner Zustände größerer Zustandsgraphen, das Senden von Nachrichten an andere Entitäten oder deren Aktivierung.
Aktionen können weiterhin den Zuständen zugeordnet werden, sie werden dann beim Erreichen des Zustandes ausgeführt. Derartige Aktionen sind in der Regel implementationsabhängig (z.B. Aufblenden von Menues oder Fenstern), so daß sie im logischen Entwurf selten vorkommen. Zustandsaktionen können auch durch hierarchisch untergeordnete Zustandsgraphen beschrieben werden, so daß einer Entität allgemein eine Menge voneinander unabhängiger hierarchischer Zustandsgraphen zugeordnet ist.
_____ _____ _____ _____
| z11 |------>| z12 | | z21 |--------->| z22 |<--+
|_____|<------|_____| |_____|<---------|_____|---+
| ^ / ! / \
| | / ! / \
| _____ | / _____! / _____ \
+-->| z13 |---+ +---| z23 | | z24 |
|_____| +-->|_____| +--->|_____|---+
/ \ | V
/ \ _____ _____
/ \ | z25+|-------->| z26-|
/ \ |_____| |_____|
_____ _____
| z14+|------>| z15-| + Initialzustände \ der untergeord-
|_____| |_____| - Finalzustände / neten Graphen
Voneinander unabhängige hierarchische Zustandsgraphen
Sachverhalte, die schon durch die Basisanalyse beschrieben wurden, dürfen nur in die Zustandsgraphen aufgenommen werden, wenn sie ausreichend allgemein sind. Wie ist das zu verstehen? Häufig werden Arbeitspläne, die keine Parallelität besitzen, in Zustandsgraphen überführt. Dabei wird in der Regel nicht berücksichtigt, daß diese Arbeitspläne sehr verschieden voneinander sind. Jeder Operation in einem solchen Arbeitsplan muß ein Zustand zugeordnet werden, damit muß auch jedem möglichen Arbeitsplan ein konkreter Zustandsgraph entsprechen. Dies führt zu einer unnötig hohen Anzahl von Zustandsgraphen in der Steuerung. Aus diesem Grunde sollten Arbeitspläne stets durch Entitätsbeziehungen und nicht durch Zustandsgraphen beschrieben werden.
Die oben angegebene Regel impliziert aber auch die Möglichkeit der Darstellung solcher Sachverhalte in Zustandsgraphen. Wann sind diese nun "ausreichend allgemein"? Wie wir in der Basisanalyse des Flexiblen Fertigungssystems gesehen haben, ist beispielsweise für jeden Palettenauftrag ein Auf- und ein Abspannen erforderlich. Diese Operationen erscheinen auch in der Prozeßstruktur des FMS-Auftrags. Der Sachverhalt ist jedoch so allgemein, daß es möglich wird, den FMS-Auftrag als Struktur auf Palettenaufträgen zu hantieren und die Auslösung der Spannaufträge in den Zustandsgraphen der Palettenaufträge aufzunehmen (vgl. Zustand 'aktiviert', Abschnitt 8.2.).
Da Prozesse ebenso wie Entitäten durch Zustandsgraphen beschrieben werden können, erscheint es naheliegend, Prozesse und Entitäten in der Steuerung einheitlich zu hantieren. Es soll trotzdem darauf hingewiesen werden, daß Prozesse keine Entitäten sind, da ihnen kein Entsprechung in der Basis zugeordnet werden kann. Sie können zwar in einer Entitätsstruktur erscheinen, allerdings nur soweit, wie auch durch sie nur Nachrichten an andere Prozesse oder Entitäten gesendet werden.
Prinzipiell können Prozesse, die mit Zustandsgraphen beschrieben werden, wie Entitäten weiterbehandelt und durch einen Zustandsgrapheninterpreter bearbeitet werden.
Es kann in der Steuerung auch Prozesse geben, die andere Steuerungsprozesse steuern, z.B. Kommunikationsprozesse. Für diese stellen die zu steuernden Prozesse Basisprozesse dar, sie können also daraufhin analysiert werden und über Entitäten verfügen, die ihre Entsprechung nicht im stofflich-energetischen Basisprozeß sondern in einem informationellen Basisprozeß besitzen. Solche Entitäten wollen wir "Steuerungsentitäten" nennen, während die bisher betrachteten Entitäten "Basisentitäten" heißen mögen. Es sei hervorgehoben, daß die Steuerungsentitäten nicht durch die hierarchische Struktur der Steuerung bedingt sind, diese liegt in der hierarchischen Basisprozeßstruktur begründet, sondern durch die Tatsache, daß die Steuerung ebenfalls bestimmte Prozesse außer ihrer eigentlichen Funktion ausführen muß. Dazu gehören insbesondere die Kommunikationsprozesse sowohl mit anderen Steuerungsprozessen als auch mit der Umgebung (vgl. WUNSCH).
| voriger Abschnitt | Inhalt der Dissertation |
|
<F>-soft Homepage |
nächster Abschnitt |
Original © 1990 by Dresden University
of Technology; Dept. of Information Science; Applied Computer Science