Let It Flow in Java

Posted on by
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!

Posted on by
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!→

How To Set Up a Continuous Integration Process in the Cloud

Posted on by

If it’s not on Maven Central, it doesn’t exist! Having a library not on Maven Central or at least on Bintray is not state of the art. I mean, we are in 2016 and most of the developers would like to use Maven, Gradle or other modern build systems for resolving library dependencies against artifact repositories automatically. However, the challenge is not only to get a library into these repositories anyhow, but to get them in automatically through a continuous integration process. I took the opportunity to set up such a process for a standardization organization, members of which are Continue reading How To Set Up a Continuous Integration Process in the Cloud→

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

Posted on by

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

Posted on by

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

Posted on by

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

Posted on by
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

Posted on by
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

Posted on by

“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

Posted on by

“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→