\’Go to OOP\‘ Der logische Weg vom funktionalen zum objektorientierten Programmieren – Teil 1

Dennoch findet eine stetige Weiterentwicklung der Programmierung statt – meist in logischen Schritten, die den Workflow bei der Applikationsprogrammierung optimieren. Im Rahmen dieser Betrachtung wird Ihnen am Beispiel einer einfachen Timer-Applikation erläutert, wie dabei der \’natürliche\‘ Weg von der funktionalen zur objektorientierten Programmierung führt. \’Der Einstieg\‘ – oder \’Wie wir (fast) alle mal begonnen haben\‘ Alle Daten in einer großen globalen Variablen-Liste deklarieren, im Programmcode munter darauf zugreifen, vielleicht sogar aus einem einzigen Programmbaustein – das ist ein Programmierstil, der pragmatisch zum Ziel führt und deswegen auch heute nicht vollständig ausgestorben ist. Dafür spricht: Viele SPS-Applikationen wurden so erfolgreich realisiert. Problematisch wird es, wenn Fehler in einem solchen Programmcode gesucht werden müssen, oder wenn die Applikation angepasst werden soll. Auch ist es mühsam, Teile des Programmcodes für andere Applikationen wiederzuverwenden. Spätestens dann beginnen SPS-Programmierer darüber nachzudenken, wie sie Ihre Applikation verbessern können. 1. Verbesserungsschritt: Strukturierung der Daten und deren Verwendung Die IEC61131-3 definiert mächtige Hilfsmittel zur Strukturierung: z.B. Funktionen (Fun), die der Programmierer für abgegrenzte Aufgaben mit einem Rückgabe-Wert von Hauptroutinen beliebig aufrufen kann. Oder Strukturen (Struct) zum Zusammenfassen von Variablen. Diese Mittel setzen erste Forderungen zur strukturierten Programmierung um, wie sie der niederländische Informatiker Edsger Dijkstra (1930-2002) aufgestellt hat (\’Go To Statement Considered Harmfulm,\‘ 1968 sowie \’Structured Programming\‘, 1972). Im Beispiel unserer Aufgabe werden dazu verschiedene Timer als Instanz einer Struktur deklariert. Darüber hinaus erfolgt die Bearbeitung mit Hilfe von speziellen Funktionen, wie z.B. MyClockGetTime, MyClockSetTime, MyClockStartTime, MyClockStopTime. Damit wird die Verwendung unterschiedlicher Timer bereits deutlich vereinfacht, weil jeder Funktionsaufruf seine eigenen Daten übergeben bekommt bzw. zurückliefert. Allerdings muss die Datenübergabe mit dem exakten Datentyp erfolgen. Auch ist es nicht möglich, alternativen Code während der Ausführung zu verwenden. 2. Verbesserungsschritt: Zusammenfassung von Daten und Code in Funktionsbausteinen (FB) Im ersten Schritt waren Daten und Code noch ohne erkennbaren Bezug zueinander strukturiert. Mit Funktionsbausteinen nach IEC61131-3 kann der Applikationsprogrammierer seine Datenstruktur zusammen mit deren Ausführung erstellen. Die eigentliche Datenallokation erfolgt bei der Instanziierung eines FBs. Mit jeder Instanz wird somit ein unabhängiger Datensatz angelegt, der vom identischen Programmcode bearbeitet wird. Durch die Deklaration von Eingangs- (VAR_Input) und Ausgangsvariablen (VAR_Output) ist es möglich, auf die Daten innerhalb der Instanz zuzugreifen. Instanzen können einzeln, aber auch als Arrays angelegt und somit weiter strukturiert werden. Nachteil vom FB: Um die Abarbeitung flexibel durchführen zu können, sind mitunter zahlreiche VAR_Inputs erforderlich, die wiederum dem exakten Typ der VAR_Input-Variablen entsprechen müssen. Sollen innerhalb des FBs alternative Programm-Sequenzen durchlaufen werden, so ist zusätzlicher Programmcode zur Verzweigung erforderlich, der nicht zur eigentlichen Funktion gehört. 3. Verbesserungsschritt: FBs mit Aktionen Aktionen von FBs beseitigen einen Teil dieser Nachteile. Sie wurden von den Vätern der IEC61131-3 zwar eigentlich für Objekte vorgesehen, die in Ablaufsprache erstellt werden. Deren Erweiterung auf alle FBs hat sich im IEC61131-3 Programmiersystem CoDeSys aber seit vielen Jahren bewährt: Zusätzlich zu den oben beschriebenen Standard-Eigenschaften von FBs kann die Applikation diese Aktionen vom FB oder aber übergeordneten Bausteinen direkt aufrufen. Das heißt: Der Aktions-code wird auf den Daten der FB-Instanz ausgeführt, allerdings unabhängig von anderen Aktionen oder dem Code im Rumpf des FB. Mit den verfügbaren Aktionen können somit unterschiedliche Ausführungsvarianten eines Objekts definiert werden. Mit dem Aufruf wird somit entschieden, welche Aktion und damit welche Variante ausgeführt werden soll. Verzweigungen für unterschiedliche Aufgaben sind in der Aktion nicht mehr erforderlich. Allerdings ermöglichen Aktionen keine Eingangsdaten (VAR_Input). Auch ist es nicht möglich, identischen Code innerhalb von Aktionen für unterschiedliche FBs zu verwenden. 4. Verbesserungsschritt: FBs mit Methoden Methoden sind Bausteine, die so in der IEC61131-3 ursprünglich nicht definiert waren. Wie auch Aktionen, sind Methoden nichts anderes als Funktionen, die einem FB zugeordnet sind. Sie können allerdings jetzt eigene Parameter haben, um deren Ausführung noch flexibler und unabhängiger voneinander zu gestalten. 5. Verbesserungsschritt: FB implementiert Interface(s) Schon Methoden sind neue Objekte in der IEC61131-3, deren Nutzen sich recht einfach erschließt. Mit dem nächsten neuen Objekt \’Interface\‘ begeben wir uns nun endgültig in die objektorientierte Programmierung. Im Gegensatz zu den Programmen, Funktionsbausteinen, Funktionen, Aktionen und Methoden enthalten Interfaces keinen Code. Wofür benötigt man sie dann? Wie der Name schon sagt, handelt es sich dabei um die Beschreibung einer Schnittstelle für den Aufruf von Methoden. Diese Beschreibung ist an einer Stelle einheitlich festlegt. Das bedeutet: Ein Interface definiert einen Satz von Methoden und deren Aufrufparameter. Dabei sind die Methoden im Interface selbst leer – es soll ja kein Code, sondern nur die Schnittstelle definiert werden. Implementiert nun ein FB ein oder mehrere Interfaces, so müssen alle im Interface definierten Methoden für diesen FB ausprogrammiert werden. Das hat mehrere Vorteile: Einerseits kann man durch Definition des Interfaces die Aufrufschnittstelle für einen FB an einer Stelle einheitlich definieren. Das ist insbesondere dann interessant, wenn es mehrere unterschiedliche Einheiten in einer Applikation gibt, die aber identisch aufgerufen werden. Beispiele dafür gibt es in der Automatisierung zur Genüge: – Alle Antriebe (unabhängig von Hersteller, Busanbindung, Leistungsklasse) unterstützen Funktionen wie \’Homing\‘, \’Reset\‘ oder \’Fahren auf Zielposition\‘. – Jeder Feldbus hat Funktionen zum Datenversand und -empfang. – Die meisten mechatronischen Einheiten müssen per Software eingeschaltet (enabled) werden und liefern ein Diagnosesignal zurück. Mit der zentralen Definition eines Interfaces kann der Programmierer sicherstellen, dass keine Funktion für den FB vergessen wird. Sollte das Interface verändert oder erweitert werden müssen, so geschieht das an einer zentralen Stelle. Auch überwacht der Compiler, dass die Implementierung z.B. einer hinzugefügten Methode wirklich vorgenommen wurde. Ein noch größerer Vorteil: Durch die Implementierung von Interfaces in unterschiedlichen Einheiten können natürlich die Implementierungen der Methoden ganz individuell erfolgen. Dennoch bleibt der Aufruf der Methoden identisch. \“Moment mal!\“, mag der fachkundige Leser dieser Zeilen jetzt einwenden, \“Ich muss ja die Methode als Teil einer FB-Instanz aufrufen! Dadurch ändert sich zwar der Methodenaufruf nicht, er enthält aber den Instanznamen!\“ Dieser Einwand ist natürlich berechtigt. Aber anders als beim normalen FB kann der Zugriff nun z.B. in Arrays auch über die implementierte Schnittstelle erfolgen. Das heißt: Beim eigentlichen Aufruf der Methode spielt es keine Rolle mehr, von welcher Instanz und mit welcher konkreten Implementierung er vorgenommen wird. Diese Zuordnung erfolgt mit dem Auffüllen des Arrays als Feld vom \’Datentyp\‘ Interface. Und das ist natürlich eine extreme Vereinfachung, wenn eine größere Menge von Methoden ähnlichen Typs, aber unterschiedlicher konkreter Umsetzung aufgerufen werden soll. Weitere Schritte Mit Interfaces und Methoden hat man die OOP aber bei Weitem nicht ausgereizt. Warum sollte man Methoden nicht in anderen FBs wiederverwenden? Was ist mit Eigenschaften (Properties) von FBs? Welche weiteren Möglichkeiten lassen sich aus dieser Denkweise ableiten? Fortsetzung folgt… Fazit Der logische Weg, der bei der Optimierung des Programmierstils eingeschlagen wurde, führt zur OOP – und er lässt sich noch weitergehen, ohne die vertraute Oberfläche der IEC61131-3 verlassen zu müssen! Schließlich werden alle beschriebenen Eigenschaften in der dritten Revision der Norm bereits enthalten sein.