Kreisfluß – Rückgekoppelte Systeme mit Flow-Design

Möbius Band als Sinnbild eines unendlichen nichttrivialen Zirkels unter einer filigranen Konstruktion

Fita de Möbius – Copyright Flavio Serafini, published under CC here Jede abgrenzbare Software ist ein technisches System. Wikipedia definiert ein technische System als Abbild (Modell) eines in der Regel komplexen technischen Produktes. Dabei werden die Wechselwirkungen zwischen den Komponenten des Systems und zwischen dem System und seiner Umgebung abgebildet und untersucht. Auf Software bezogen erfolgt diese Wechselwirkung durch Informationsflüsse: Eine Eingabe wird vom Software-System in eine Ausgabe transformiert. Das lässt sich bei jedem simplen GUI-basierten Programm verfolgen, welches eine menschliche Eingabe durch Maus oder Tastatur in eine Ausgabe auf dem Bildschirm umsetzt. Dieses System folgt einer linearen Kausalkette: das Continue reading Kreisfluß – Rückgekoppelte Systeme mit Flow-Design

Mit den Fehlern leben – Fehlerbehandlung in Scala-Flow-Design

“If debugging is the process of removing software bugs, then programming must be the process of putting them in.” – Edsger Dijkstra Klar, Fehlerbehandlung muss sein, auch in Flow-Design. Dabei sind im Prinzip zwei Fehlerarten zu unterscheiden. Erwartete oder vorhersehbare Fehler – Dies sind Fehlersituation, die Bestandteil des Modells sind, welches mit Flow-Design entworfen und realisiert wird. Sie müssen über das Flow-Design-Modell darstellbar sein, am besten deklarativ. Der Benutzer einer Funktionseinheit wird damit gezwungen, sich mit dem Fehlerfall im Modell auseinanderzusetzen. Unerwartete Fehler – Mit diesen Fehlern muss vor allem die Infrastruktur, die Programmablaufumgebung umgehen können, denn es sind am Continue reading Mit den Fehlern leben – Fehlerbehandlung in Scala-Flow-Design

Auf den Standpunkt kommt es an – Abstraktionsebenen im Flow-Design

“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.” – Martin Fowler Bis jetzt hatten alle in meinem Beispiel verwendeten Funktionseinheiten nur einen Ausgang und das Modell bewegte sich auf nur einer Abstraktionsebene. Jetzt möchte ich eine Funktionseinheit mit zwei Ausgängen und dem Modell eine zweite Abstraktionsebene hinzufügen, um zu demonstrieren, wie elegant man in Flow-Design mit verschiedenen Abstraktionsebenen umgehen kann, indem mehrere Funktionseinheiten zu einer neuen, höher abstrahierten Funktionseinheit zusammengefasst werden. Für mich ist dies, neben der prinzipiellen Unabhängigkeit der Funktionseinheiten voneinander, die zweite revolutionäre Neuerung, die Flow-Design kennzeichnet. Dadurch Continue reading Auf den Standpunkt kommt es an – Abstraktionsebenen im Flow-Design

Syntactic Sugar … und gut umrühren

Programs must be written for people to read, and only incidentally for machines to execute. – Abelson / Sussman Im letzten Artikel hatte ich gezeigt, wie das Scala-Sprachkonzept der Traits zu einer kompakten Implementierung von Flow-Design-Funktionseinheiten führt. Es lässt sich jedoch noch mehr an der Lesbarkeit verbessern. Beim Verbinden der Funktionseinheiten musste auf der rechten Seite der Operation bindOutputTo immer neben der Funktionseinheit auch der Eingangsport angegeben werden, auch wenn die Funktionseinheit nur einen Eingang hatte. object RunFlow { def main(args: Array[String]) { … println(“bind them…”) reverse bindOutputTo toLower.input reverse bindOutputTo toUpper.input toLower bindOutputTo collector.input1 toUpper bindOutputTo collector.input2 collector bindOutputTo(msg Continue reading Syntactic Sugar … und gut umrühren

Ein spezieller Charakterzug – Traits für Flow-Design in Scala

Copy and paste is a design error. – David Parnas Im letzten Artikel haben wir die Funktionseinheiten in Scala zusammengesteckt. Aber bei der Implementierung der Funktionseinheiten wiederholen sich viele Methoden immer wieder, ohne dass sie sich von einer Funktionseinheit zur anderen unterscheiden. Zum Beispiel ist die Methode input gleichlautend sowohl in der Funktionseinheit ToUpper class ToUpper { def input(msg: String) { process(msg) } … } als auch in der Funktionseinheit ToLower zu finden. class ToLower { def input(msg: String) { process(msg) } … } Traits Dies widerspricht ganz dem DRY Prinzip. Schön wäre es doch, wenn man die Ein- und Continue reading Ein spezieller Charakterzug – Traits für Flow-Design in Scala

Steckspiele – Flow-Design-Funktionseinheiten in Scala verbinden

Im letzten Artikel hatte ich an einem Beispiel gezeigt, wie eine EBC-Funktionseinheit in Scala aussehen könnte. Nun soll es darum gehen, wie mehrere solcher Funktionseinheiten zusammengesteckt werden können. Dazu soll folgendes Flow-Design-Modell als Beispiel Verwendung finden: Die Semantik des Modells ist extra simpel gehalten: Eine Zeichenkette fließt in die Funktionseinheit Reverse hinein, die die Zeichen in ihrer Reihenfolge umdreht. Die umgedrehte Zeichenkette fließt danach jeweils in die beiden Funktionseinheiten ToUpper und ToLower. Wie die Namen der beiden Einheiten nahelegen, wandelt die eine alle Kleinbuchstaben in Großbuchstaben um, während die andere genau das Umgekehrte vollbringt. Die beiden veränderten Zeichenketten werden dann Continue reading Steckspiele – Flow-Design-Funktionseinheiten in Scala verbinden

Treppengeplätscher – Flow-Design in Scala

Wie ich in meinem einleitenden Artikel zu diesem Blog geschrieben hatte, möchte ich den Entwicklungsweg, den das Flow-Design-Paradigma genommen hat, nachgehen. Deswegen soll es zunächst darum gehen, Event-Based Components (EBC), wie sie Ralf Westphal in seinem Artikel skizziert hat, in Scala zu realisieren. Das EVA-Prinzip Aus meiner Sicht adressiert EBC vor allem ein Grundproblem der Software-Entwicklung – Abhängigkeiten. Der EBC-Ansatz versucht den Entwickler in der Lösung dieses Problems zu unterstützen, indem Funktionalität in Funktionseinheiten (engl. Function Unit) gekapselt wird, die ganz dem EVA-Prinzip (Eingabe-Verarbeitung-Ausgabe) folgen. Eine Funktionseinheit hat einfließende Nachrichten, die sie verarbeitet. Das Ergebnis dieser Verarbeitung verlässt die Funktionseinheit wiederum als Continue reading Treppengeplätscher – Flow-Design in Scala