…to this website in support of my book, A Fly-By-Wire Architecture for Multi-Threaded Windows Apps, available for Kindle and in softcover from Amazon.com and Barnes and Noble.
The book presents techniques for structuring multi-threaded Windows applications. It teaches how to use those techniques to develop complex but reliable Windows programs quickly. The only prerequisites are an understanding of object-oriented programming and some familiarity with Windows application development.
Well-behaved Windows programs that perform lengthy processing or that wait for stimulus or information from outside of the program make use of multiple threads. They must. For, otherwise, the programs will be slow to repaint their Graphical User Interface or GUI (after dragging or being uncovered), will be slow to respond to input from users, and will generally degrade the performance of the computer that is executing them. The architecture I present makes the design of multi-threaded programs easy and straightforward.
The code for a complete demonstration Windows application—FBWwinAppDemo—written in C# accompanies this book, and is avaliable for download on the Downloads tab. To make the demonstration interesting, we imagine that FBWwinAppDemo controls a simple robot that can sense the infrared radiation emitted by a person and follow him around a room.
These concepts come out of my thirty-five years as a computer engineer working at the nexus of software and hardware, where the rubber meets the road. Working there showed me the value of a fly-by-wire architecture. Fly-by-wire systems employ a local-area-network (LAN) as a backbone upon which to hang the major components of the system. The physical connection among them is only the wires of the LAN. The modules of functionality communicate by way of messages over the LAN.
My idea is to use the fly-by-wire concepts in complex Windows applications. I don’t mean as part of a system in which the Windows app is one of the components, but rather within the Windows program itself. In such a program, the nuggets of functionality are classes that do most of their processing in child threads. These components of the program communicate using messages sent on the software equivalent of the LAN in fly-by-wire systems, that is, on a “logical bus” within the program itself.
An advantage to this approach is that the highest-level diagram of every fly-by-wire Windows app looks like the figure to the left. It is a collection of boxes representing nuggets of functionality, interconnected by the logical bus. Add as many boxes as you need, give them names that suggest their roles in the program, define the messages they send and the payloads the messages carry, and you’ve got your high-level design.
Using a logical bus over which the components of the program communicate makes possible a very powerful debugging and testing aid. The program may include a special component with its own GUI, whose job is to display and/or log messages that appear on the bus. This is analogous to “sniffers,” devices that record and display communication between two devices over an RS232 connection, say. Being able to see who said what to whom, and when, is very helpful in debugging.
As developers, you can equip the debugging component’s GUI with the ability to interact with you and interject messages, messages that will, eventually, come from a program element that is not yet implemented. This helps you test the program as you breathe life into it.
The fly-by-wire architecture also makes unit testing more feasible. In a program structured like this, many modules within the program function by responding to messages by sending messages. Thus, unit-test code can stimulate a module-under-test by sending it messages, and then assess its responses. A module-under-test won’t know that the messages coming to it are part of a testing effort, so it responds as it is programmed to respond.