Framework für Zustandsorientierte Programmierung

Diplomarbeit von Christian Silberbauer

Zusammenfassung:

Diese Ausarbeitung beschreibt ein Framework zur Unterstützung der Zustandsorientierten Programmierung. Mit Zustandsorientierter Programmierung ist hier ein Programmierparadigma gemeint, das Variablen und deren Zustände in den Mittelpunkt stellt. Die Variablen werden funktional in Beziehung gesetzt. Ändert sich der Zustand einer Variablen, so werden die davon abhängenden Variablen angepasst.

Die Zustandsorientierung kann auf der Objektorientierung basieren. Genau dies ist beim hier beschriebenen Framework (im Folgenden auch Zustandsframework genannt) der Fall. Das Zustandsframework ist in der objektorientierten Programmiersprache C# entwickelt. Es umfasst hauptsächlich sog. Zustandsklassen und erlaubt eine Zustandsorientierte Programmierung, indem Attribute von Klassen durch jene Zustandsklassen gekapselt sind. Die Zustandsklassen fungieren gewissermaßen als Container für Attribute und kontrollieren deren Zugriff, insbesondere deren Manipulationen.

Mitarbeiter (Employee) haben eine Arbeitsleistung (performance). Deren Chef (Boss) wacht über ihre durchschnittliche Arbeitsleistung (staffPerformance). Sinkt diese unter 98%, so werden ein paar Mitarbeiter entlassen. Die beiden Performance-Attribute sind eigentlich vom Typ double, werden aber durch eine sog. Einfache Zustandsklasse (State) bzw. eine Aggregierte Zustandsklasse (AggregateState) gekapselt. Im Code-Listing nicht abgebildet ist die Konfiguration der entsprechenden Zustandsobjekte. Insbesondere die Aggregierten Zustandsobjekte müssen durch eine Aggregatsfunktion zur Durchschnittbildung parametrisiert werden und die zugehörigen Einfachen Zustandsobjekte müssen als Kind-Zustände definiert werden. Darüber hinaus ist die Methode PerformanceChanged() als sog. Transitions-Listener für staffPerformance zu definieren. Ändert sich also die durchschnittliche Arbeitsleistung der Belegschaft bzw. findet diesbezüglich ein Zustandsübergang bzw. eine Transition statt, so wird PerformanceChanged aufgerufen.

Unter Verwendung des Zustandsframeworks lassen sich Attribute durch deklarative Programmierung funktional miteinander in Verbindung bringen, Zustandsübergänge lassen sich verfolgen und, wie später noch ersichtlich wird, lassen sich vom Zustandsobjekt vorgesehene Zustandsübergänge sogar blockieren. Letzteres bedeutet, dass der Client bei Transitionen die Möglichkeit hat, entsprechende Aktivitäten durchzuführen. Sind diese nicht erfolgreich, so kann der Client bestimmen, dass das Zustandsobjekt in seinem alten Zustand verharrt.

Alles in Allem ist das Zustandsframework ein hilfreiches Werkzeug, um Zusammenhänge zwischen Attributen einfach herzustellen und damit eine zustandorientierte Sichtweise in der Programmierung zu fördern.

Entstanden ist das Framework in Folge einer Beschäftigung des Autors bei Siemens Corporate Research in Princeton in den USA. Dort wird ein Verteiltes System entwickelt. Der Service-Container des Systems hat ein komplexes Lifecycle-Management für seine Komponenten zu realisieren. Entsprechend ist die Ausrichtung des Zustandsframeworks. Seine Zustandsklassen sind nach den Anforderungen des Service-Containers von Siemens entworfen und sind daher keine allgemeine Sammlung von Zustandsklassen für Zustandsorientierte Programmierung. Dennoch sind vor allem die primitiveren Zustandsklassen recht universell einsetzbar. Außerdem ist eine Erweiterung des Frameworks um weitere Zustandsklassen sehr einfach möglich.

Inhaltsverzeichnis:

Textprobe:

Kapitel 6.3, Klasse AggregateState:

Der ServiceManager eines SDS Containers überwacht einen einzelnen SDS Service, welcher im Allgemeinen mehrere SDS Components umfasst. Der ServiceManager hat zwei aggregierte Zustände seiner Komponenten, erstens den Error State und zweitens den Availability Indicator.

Der Error State eines Services ist nur dann NoError, wenn sämtliche seiner Komponenten den Error State NoError innehaben. Sobald wenigstens eine Komponente Failed ist, ist der Error State des Services auch Failed. Unter der Annahme, dass es eine Reihenfolge unter den einzelnen Error States gibt und Failed der kleinere Wert und NoError der größere Wert ist, kann man sagen, dass der Error State eines Services über das Minimum der Error States seiner Komponenten definiert ist.

Der Availability Indicator eines Services hingegen ist das arithmetische Mittel der Availability Indicators seiner Komponenten. Zum Beispiel hat ein Service zwei Komponenten A und B mit den Availibility Indicators 0,67 und 0,97, so hat der entsprechende Service Availability Indicator den Wert 0,82.

Zum Zwecke der Integration einzelner Zustände, ist die Klasse AggregateState implementiert. Den Prototyp der Klasse zeigt das nächste Listing, deren Design dem Strategy Pattern folgt. Die Intention dieses Patterns ist:

Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it.

Demgemäß ist die Aggregatsfunktion, abgebildet durch IAggregation, vom eigentlichen AggregateState abgekapselt. Die Aggregatsfunktion konfiguriert den aggregierten Zustand sozusagen. Heißt, es können ganz einfach verschiedene Arten von Aggregationen definiert und verwendet werden, z.B. eine Aggregatsklasse, die den minimalen Zustand all seiner Kindzustände errechnet oder den maximalen Zustand oder auch den Durchschnitt aller Kindzustände bildet.