Let It Flow in Java

Waterfall at Java

As announced in my previous article, where I had introduced Flow Design, I want to show a concrete implementation in Java. The code for this example may be found on GitHub. I will follow the blog article “IODA Architecture by Example” of Ralf Westphal which made a Flow Design and implementation for the following scenario: Build an application that translates a Roman number entered by the user into an Arabic number and vice versa. It may be valuable to read his article too, to get further details. However, I will repeat his steps (sometimes a little bit shortened) for letting Continue reading Let It Flow in Java

Go Beyond Object Oriented Design — Let it flow!

Strutured Flowing Water

Why is software engineering so different from all other engineering dealing with real parts? Why is the design of a software system almost not recognizable anymore in the code? I’m quite sure, software engineering can get closer to how other engineering disciplines are doing it. It is possible to make design directly recognizable in code. This blog article series is about a possible approach. Look at this block diagram about an Apple I Video Terminal: It describes in an abstract way the components the video terminal is build from and how they interact and depend on. E.g., data is flowing Continue reading Go Beyond Object Oriented Design — Let it flow!

Alle Wege führen nach Rom – IODA-Architektur mit XtendFlow am Beispiel

Conceptual Art by Cildo Meireles, Madrid – Copyright Maureen Barlin, published under CC BY-NC-ND 2.0 here Nun habe ich endlich mal Zeit gefunden, eine echte nicht-triviale, wenn auch einfache, Implementierung mit XtendFlow zu realisieren. Ich nehme dabei wieder mal, wie so oft, einen Artikel von Ralf Westphal als Vorlage. Er hat in seinem Artikel „IODA Architecture by Example“ für die leicht erweiterte Code-Kata Roman Numerals eine IODA-Architektur designt und in C# realisiert. Etwas Historie Dies hat als erste XtendFlow-Implementierung auf zweifache Weise seinen Reiz. Zum ersten nimmt mir dies Design-Arbeit ab und ermöglicht einen direkten Vergleich zwischen einer C#-basierten und Continue reading Alle Wege führen nach Rom – IODA-Architektur mit XtendFlow am Beispiel

Alles neu macht der … April – vollständige interne DSL für XtendFlow

Die im letzten Artikel vorgestellte Lösung zur Umgehung des Xtend-Problems, welches das Komponieren von Konstruktor-Code mit generiertem Code, erzeugt durch den Active-Annotation-Prozessor, verhindert, ist am Ende eben nur ein Workaround – ein hässlicher noch dazu, bei dem Initialisierungscode im Konstruktor als Java-Code (mit Semikola) niedergeschrieben werden muss. Dies veranlasste mich, noch mal grundsätzlicher über die Formalisierung einer FlowDesign-Spezifikation in Xtend nachzudenken. Ließe sich nicht auch das Anstoßen eines Flusses durch einen initialen Wert oder das Weiterleiten der Berechnungsergebnissen einer Funktionseinheit an einen Ausgabeport  expliziter als durch eine Methodenimplementierung ausdrücken, um auch den Wiedererkennungeffekt beim Lesen zu erhöhen, ähnlich dem Wiedererkennungseffekt Continue reading Alles neu macht der … April – vollständige interne DSL für XtendFlow

Nachtrag zu XtendFlow

Im letzte Artikel hatte ich erwähnt, dass eine angezeigte Warnung für die bind Methode der integrierenden Funktionseinheit Normalize eine Unzulänglichkeit des Xtend-Compilers sei und diese in der nächsten Version Xtext/Xtend behoben sein wird. Leider erwies sich die Korrektur in Xtend als schwieriger als gedacht, da eine Lösung die Komponierbarkeit von Xtend-Ausdrücken erfordert, was eine signifikante mit nicht geringem Aufwand verbundene Erweiterung von Xtend's Active-Annotation-Framework bedeutet. Das Xtext/Xtend-Team wusste noch nicht, wann sie das angehen werden. Deshalb habe ich mir noch mal Gedanken gemacht, wie man dieses Problem anders umgehen kann und habe eine Lösung gefunden, die mir im Nachhinein auch Continue reading Nachtrag zu XtendFlow

Extend Your Flow Horizon – Flow-Design mit Xtend

Kepler Module in X-Form vor dem Horzont der aufegehnden Sonne vom der ISS aus gesehen

Kepler on the Horizon – Copyright NASA, published under CC here Flow-Design ist ein allgemeingültiges Design- und Programmierparadigma. Ralf Westphal hat dies schon mehrfach gezeigt – natürlich für C#, aber auch für Ruby. Es existiert eine Umsetzung in Java von Olaf Krummnow (leider ist sein Blog nicht mehr erreichbar). Ich habe es hier in meinem Blog für Scala gezeigt. Natürlich ist jede Sprache unterschiedlich stark prädestiniert für Flow-Design – wie prägnant sich Ports und deren Verbindungen spezifizieren lassen. Um es einigermaßen elegant, ohne viel syntaktisches Rauschen ausdrücken zu können, benötigt man schon Lambda-Ausdrücke in der Sprache. Ich will es auch Continue reading Extend Your Flow Horizon – Flow-Design mit Xtend

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