Event-Based Components

Easily Parallelize Operations in Flows Using the Flow Execution Engine

My previous article introduced the Flow Execution Engine NPantaRhei (download here from github). It showed how to define a data flow and register its operations. By default such flows are executed synchronously and sequentially – although in the background with regard to their initiator. But it´s easy to parallelize execution of operations. Here´s a first suggestion for how to run operations concurrently in the example given in the first article. The dots in the operations signify asynchronous operation: ......

Introduction to the Flow Execution Engine NPantaRhei

How can data processing flows be implemented in an easy manner? What I call data flow processing – or flow design (FD) - I´ve defined here and described here for example. (Although this might look like Flow-Based Programming (FBP) it´s just related. FBP is all about concurrent programming, but FD starts much simpler with synchronous sequential programming.) And how such flows can be translated into a modern OO language like C# is described here. Such translation is pretty conventional, although it ......

Flowing Bowling Game Kata I

Ron Jeffries challenged me to show how Flow-Design and Event-Based Components can help software development. This is the problem he posed in the Software Craftsmanship discussion group: Solve bowling scoring. Here is the specification. Note that this is a simpler version than the one Bob Martin often uses. I'll take questions if you have any. Given a list of the rolls of a legal game of ten pin bowling, which you may assume are provided without error or omission, produce the total, final, score of ......

Flow-Design Cheat Sheet – Part II, Translation

In my previous post I summarized the notation for Flow-Design (FD) diagrams. Now is the time to show you how to translate those diagrams into code. Hopefully you feel how different this is from UML. UML leaves you alone with your sequence diagram or component diagram or activity diagram. They leave it to you how to translate your elaborate design into code. Or maybe UML thinks it´s so easy no further explanations are needed? I don´t know. I just know that, as soon as people stop designing with UML ......

Flow-Design Cheat Sheet – Part I, Notation

You want to avoid the pitfalls of object oriented design? Then this is the right place to start. Use Flow-Oriented Analysis (FOA) and –Design (FOD or just FD for Flow-Design) to understand a problem domain and design a software solution. Flow-Orientation as described here is related to Flow-Based Programming, Event-Based Programming, Business Process Modelling, and even Event-Driven Architectures. But even though “thinking in flows” is not new, I found it helpful to deviate from those precursors ......

Going asynchronous - AOP made easy with Event-Based Components – Part III

Logging, validation, exception handling: that´s easy aspects to insert into an Event-Based Components design as I´ve shown in my previous post. But what about multi-threading? Or better: parallel and asynchronous processing? In this article I want to show you, how you could approach multi-core programming using aspects you insert into an existing EBC architecture. Asynchronous processing Why use multiple threads at all? It´s because you either want to hide latency, or you want to decrease latency, ......

Aspect Oriented Programming made easy with Event-Based Components – Part II

In my previous post I described the architecture for a small application to index .TXT files. Here´s are the napkins with my design EBC diagrams so far: Currently the implementation is working in a synchronous and sequential mode. Now, today I want to move on and introduce a couple of aspects (in the AOP sense) into the design/code. I find Event-Based Component architectures very easy to extent in that regard. No special AOP tools necessary. But see for yourself… Adding a logging aspect The “Hello, ......

Aspect Oriented Programming made easy with Event-Based Components – Part I

AOP still is pretty much a pain when living according to “traditional” object orientation. You need fancy tools or you need to do some advanced code slinging. With Event-Based Components, though, introducing aspects is a piece of cake. Actual code is freed from tackling special concerns. Rather concerns become a matter of architecture. But see for yourself. The scenario for today is file processing. I want an application which indexes .TXT files. The program should crawl a directory hierarchy, extract ......

Using Event-Based Components for Library Development

Can Event-Based Components (EBC) be used to design libraries? Sure they can. FallenGameR asked a question along this line in response to my previous article. Let me demonstrate this with a simple library scenario: A function ToDictionary() is to be developed which converts a string like “port=8080;user=bart;passwo... into a Dictionary<string, string>. The usage should be like this: var td = new StringToDictionaryConverter(); var dict = td.Convert(“port=8080;user=... or var dict = new Dictionary<string, ......

Event-Based Components – Leaving the beaten path of canonical object orientation

Since long I´ve been doubting the canonical object oriented way of programming was of much help. I´ve never seen a “true” object oriented software system that also was maintainable. And I´ve never seen an average programmer who had an easy time coming up with an evolvable design for even a small application. The litmus test for me is to put someone in front of an empty whiteboard and ask them to quickly draw a design for, say, a Tic Tac Toe game. It´s an easy scenario, I´d say. The requirements are ......

Improving the Event-Based Components Desktop Calculator

In my previous article I designed and implemented a small desktop calculator using Event-Based Components. That was fun and went smoothly – but in the end I was in a hurry and missed a bug and a feature. In the meantime I found some time to fix both. Final architecture Let me take the opportunity to show you the application architecture in its entirety. The missing feature – Clear calculation - has already been added: This is the high level view. All activities except one are so simple, no further ......

Designing on different levels of abstractions with Event-Based Components

One of the biggest problems with object oriented designs is its inability to express architectures on different levels of abstractions. True, there are Packet Diagram, Component Diagram, and Class Diagram in UML, which are geared towards different levels of abstraction. But I ask you: How do you translate them into code? Except for Class Diagrams that´s not so easy. There are hardly any guidelines – at least when it comes to the .NET platform. What´s a component in .NET terms? What´s a packet? And ......