FAQ

OOP und UML

Müssen die objektorientierte Programmierung (OOP) und UML stets zusammen verwendet werden?

• Die kombinierte Nutzung von OOP und UML bietet viele Vorteile (s. nächste Frage), ist allerdings nicht zwangsläufig nötig. Es ist auch ohne die Verwendung von UML möglich, eine Applikation objektorientiert zu programmieren. Genauso kann UML auch in SPS-Projekten verwendet werden, die nicht objektorientiert programmiert werden bzw. wurden.

Welche Vorteile bietet es, OOP und UML zusammen zu verwenden?

• Um die Vorteile der OOP optimal zu nutzen, sollte die Struktur einer objektorientierten Software vor Implementierungsbeginn konzipiert bzw. erstellt werden (z. B.: Welche Klassen sind vorhanden, in welcher Beziehung stehen sie zueinander, welche Funktionalitäten stellen sie bereit, etc.). Vor, während und nach der Programmierung helfen Dokumentationen dabei, die Software zu verstehen, zu analysieren und zu warten.
• Als Analyse-, Design- und Dokumentationswerkzeug von Software bietet UML entsprechende Möglichkeiten, um die Applikation zu planen, zu erzeugen und zu dokumentieren. Dabei eignet sich die Verwendung von UML besonders bei objektorientierten Implementierungen, da vor allem modular aufgebaute Software mithilfe einer grafischen Sprache dargestellt werden kann.
• So wird beispielsweise das Klassendiagramm zum Analysieren und Erzeugen der Programmstruktur verwendet – und je modularer die Software aufgebaut ist, desto einfacher und effizienter kann das Klassendiagramm genutzt werden (z. B.: Grafische Darstellung von separaten Funktionsblöcken mit einzelnen Methoden zur Bereitstellung der Funktionalitäten, etc.).
• Das Zustandsdiagramm kann genutzt werden, um den Ablauf eines ereignisdiskreten Systems zu spezifizieren – und je konsequenter die Software objekt- bzw. ereignisorientiert aufgebaut ist, desto übersichtlicher und effektiver können Zustandsmaschinen entworfen werden (z. B.: Das Verhalten von Modulen/Systemen basiert auf einem Zustandsmodell mit Zuständen (wie Aufstarten, Produktion, Pausezustand) und innerhalb der Zustände werden entsprechende Funktionalitäten aufgerufen, die in Methoden (wie Aufstarten, Ausführen, Pausieren) gekapselt sind, etc.).

UML Zustandsdiagramm-Methoden mit deaktivierter "UseVarInst"-Option

Die folgenden drei Fragen beziehen sich auf Methoden, deren Implementierungssprache UML Zustandsdiagramm ist und die zusätzlich eine der nachfolgenden Bedingung erfüllen:

• Die Zustandsdiagramm-Methode gehört zu einem Programm.
• Die Zustandsdiagramm-Methode gehört zu einem Funktionsbaustein und die Option UseVarInst der Methode ist deaktiviert.

Zustandsdiagramm-Methoden, die diese Bedingungen erfüllen, werden in den folgenden Fragen als „die genannten Methoden“ bezeichnet.

Weiterführende Informationen zu der Option UseVarInst finden Sie unter UML Zustandsdiagramm > Objekteigenschaften.

Warum können die genannten Methoden nur zyklusinterne Zustände beinhalten und warum gibt es kein Online-View?

• Generell gilt, dass standardmäßig alle Daten einer Methode temporär und nur während der Ausführung einer Methode gültig sind (Stack-Variablen). Wenn Sie eine Variable einer Methode hingegen mittels VAR_INST als Instanzvariable deklarieren, wird sie nicht auf dem Methoden-Stack, sondern auf dem Stack der Funktionsbaustein-Instanz abgelegt. Sie verhält sich also wie andere Variablen der Funktionsbaustein-Instanz und wird nicht bei jedem Aufruf der Methode neu initialisiert.
• Da die Daten der genannten Zustandsdiagramm-Methode nicht als Instanzvariablen deklariert werden, handelt es sich hierbei um zyklusinterne Zustandsmaschinen. Somit werden die in den Diagrammen enthaltenen Zustände zyklusintern und nicht vom Taskzyklus geschaltet, da die Methodenausführung aufgrund der temporären Datenhaltung mit jedem Taskzyklus „neu beginnt“. Folglich ist für diese Zustandsdiagramm-Methoden auch kein Online-View möglich, da die Variablen der Zustandsmaschine temporär sind und sich der aktive Zustand innerhalb eines Zyklus mehrfach ändern kann.
• Dies steht im Gegensatz zu Zustandsdiagrammen ohne temporäre Datenhaltung (z. B. Programme oder Funktionsbausteine als Zustandsdiagramm, Funktionsbausteinmethode als Zustandsdiagramm mit aktivierter UseVarInst-Option), bei denen die Zustände standardmäßig vom Taskzyklus geschaltet werden und optional als „zyklusintern“ konfiguriert werden können.

Warum enthält die Werkzeugliste der genannten Methoden keine Composite States (zusammengesetzte Zustände), Forks (Gabelungen) und Joins (Verbindungen)?

• Da die Daten dieser Methoden temporär und nur während der Methodenausführung gültig sind, können die genannten UML Zustandsdiagramm-Methoden nur zyklusinterne Zustände besitzen (s. vorherige Frage).
• Ein Composite State müsste demzufolge auch in einem Zyklus beendet werden. Damit würde das Element stets sequenziell abgearbeitet werden, selbst wenn die Ausführung einer Region nicht abgeschlossen wird.
• Dieses Verhalten wäre damit fundamental anders als bei „normalen“ Composite States, die sich ihren internen Zustand merken können.
• Um für ein Composite State nicht verschiedene Verhaltensweisen anzubieten, je nachdem bei welcher POU-Art das Element verwendet wird, sind die Composite States in den genannten Methoden nicht erlaubt.
• Da Forks und Joins nur in Zusammenhang mit Composite States erlaubt sind, stehen auch diese Elemente in den genannten Zustandsdiagramm-Methoden nicht zur Verfügung.

Was ist bei der Programmierung der genannten Methoden zu beachten? Was könnte die Ursache für eine hohe Systemauslastung bei der Ausführung dieser Methoden sein?

• Wie in den vorherigen Fragen erläutert, handelt es sich bei den genannten UML Zustandsdiagramm-Methoden um zyklusinterne Zustandsmaschinen. Sie werden also zyklusintern und nicht vom Taskzyklus geschaltet.
• Das bedeutet, dass, wenn die Aktionen eines internen Zustands abgeschlossen sind, unmittelbar in die Transition geschaltet wird. Es wird damit sofort die Transitionsbedingung geprüft und bei erfüllter Bedingung die Transitionsaktion ausgeführt. Ebenso wird bei erfüllter Transitionsbedingung sofort anschließend in den Zielzustand geschaltet.
• Sollte die Transitionsbedingung hingegen nicht erfüllt sein, wird folglich auch nicht in den Zielzustand geschaltet und der aktuelle Zustand bleibt aktiv. Damit wird (wegen der zyklusinternen Zustände) noch im selben Zyklus erneut die DO-Aktion des aktuellen Zustands aufgerufen, falls die maximalen DO-Zyklus Aufrufe noch nicht erreicht wurden.
• Max. DO-Zyklus Aufrufe (Max. DO-cycle calls): Für einen Zustand können die maximalen DO-Zyklus Aufrufe konfiguriert werden, wobei ein Wert zwischen 1 und 32767 eingestellt werden kann. Diese Zahl gibt die maximale Anzahl an Aufrufen der DO-Aktion an.
• Folglich ist zu beachten: Sollte die Transitionsbedingung während des gesamten Taskzyklus nicht erfüllt sein, wird die DO-Aktion des aktuell aktiven Zustands in diesem Zyklus so lange ausgeführt, bis die maximalen DO-Zyklus Aufrufe dieses Zustands erreicht sind.

Beispiel: Falls für "max. DO-Zyklus Aufrufe" ein Wert von 32767 eingestellt ist und die Transitionsbedingung während des Taskzyklus unerfüllt bleibt, wird die DO-Aktion des entsprechenden Zustands 32767-mal in einem Zyklus ausgeführt! Da dies je nach Umfang der DO-Aktion zu einer hohen Systemauslastung führen kann, sollte genau geprüft werden, ob die Zustandsmaschine und speziell die Transitionsbedingungen sowie die Werte der maximalen DO-Zyklus Aufrufe korrekt konfiguriert sind und dem gewünschten Applikationsverhalten entsprechen.