Inputs and outputs will be chained together in a program to take data from a given source and translate that data into the same or different data at a specific destination. Never let the enormity of that task dissuade you from defining the program flow. A good flow is not defined all at once anyway, but in little chunks. Each chunk works with another chunk until the combined interaction forms a complete program. However, it is very useful to have an internal mental sense of what the chunks will be and how they will relate. While data is the major ingredient you are moving through a program, the means to do so involves itty bitty steps linked together. Those itty bitty steps is what is called programming statements.
Purpose of Program Flow
A program flow organizes these programming statements into various groupings. You may have one group for dealing with the network communication to access an RSS feed. Another group deals with breaking apart the RSS feed data. Another group may provide easily accessible program locations for each RSS feed part. Other groups may involve different parts of the screen tied to how you interact with the screen such as a group to deal with headlines and another group to deal with article summaries and so on. The program flow can show the major (and optionally, the minor) relationships in a program. An effective breakdown will streamline the process of putting the program together.
A program flow does not necessarily show what code you are writing, or even what code you intend to write. Instead, the program flow deals with the overall logic. The format of a program flow can be a flowchart written on paper or in a digital diagram format such as Visio, PowerPoint, Dia, or LibreOffice Impress. You can also document a program/process flow in an Excel or LibreOffice Calc spreadsheet. Another good way to define a program/process flow is in a written out document.
As an example, we will show a program flow for the Gautier RSS reader program. We will write it here and it will be the basis for how the Gautier RSS reader program operates. Note that also, that when you are looking to update an existing program, sometimes it is helpful to redo the program flow entirely based on how the program actually works versus how it was originally specified as that can portray a more accurate picture of the program.
Gautier RSS Program Flow
Need a data file that lists out each RSS feed’s name and website address. The program’s first major task is to read the RSS feeds file. Program starts → Read RSS feeds file → Maintain list of feed locations and names → Retrieve the first feed → Show a list of RSS feed names → Show a list of headlines for the first feed → Show the article summary and web link for the first headline available → User clicks different feed name → Retrieve the feed’s data → Show headlines for the retrieved feed → Show the article summary and web link for the first headline available.
That is the most basic written out program flow possible. It is only a rough draft and is ripe for improvement to clarify thought and action. Notice that we state the need to show a list of headlines despite it being the first time or subsequent times. That means we will need reuse/reapply the “same” feed data retrieval and visual presentation process on “different” feeds. That requirement is implied in the program flow. However, in the beginning, as long as we make a note about that, we can continue from what we have already stated to begin writing a program.
Program Flow Documents
A program flow can be worked on until you are comfortable using it, in conjunction with a data flow, to lead and guide your programming efforts. In my personal projects, I do not make much use of formally created process flows (sometimes I do but not often) preferring notebook paper and a pen. When working on larger professional projects (building programs for others in a formal environment) I will use digitally crafted diagrams, to-do lists, and such as I am essentially creating additional monitors in printed form to sustain the processes in my gaze as I work through multiple levels of design at the same time. Either way works but it is best to calibrate the approach to your means, time, resources, and comfort.
Program flows written out on paper are the type you use when more of the programming is organic. That is, you are relying more on your view of the system in your mind than on a concrete representation on paper. That works better when you need or want to explore the right structure for the program or you have already proceeded through many versions of the same program. The organic approach may emphasize the vision for the program over the implementation. Fewer barriers exist to making wholesale changes to the program when needed. You can do this with either smaller systems or small personal projects, but this is not recommended for larger projects.
A more detailed program flow on paper you convert to a quasi-professional digital layout (straight, consistent lines, color coding, good spacing and typography) is recommended for certain kinds of projects or situations. Yes, you can view the diagram on the screen, but it is often better to print it out so you can write on it, place it side by side with data diagrams, and maintain awareness of it as the days go on. Either way, the program flow speeds up and focuses implementation of the program in the beginning. However, as you become more familiar with the actual implementation, the program flow may become less useful to you at that point, but will serve as good documentation for those who pick up maintenance of the program later.
Program Flow Mindset
It is not obvious, but if you go back to the first article in the series, both the program and data flow work in tandem. You should see both in a way that goes beyond how they are expressed on paper. The data flow and the program flow are simply reminders at the end of the day. You use them to conform your thoughts to the reality of the technical environment in which the system inhabits. Rules exist in a computer and flow documents chart out computer-based representation of various parts of an operating whole. The true system is in the mind and the combined actions of the people and machines in the situation.
Program Flow and C++
A program flow can describe broad areas of a program and how they are related. One way to represent this in C++ is in the form of classes. A class can be used in several different ways. Most of the approaches to using a class in C++ can be combined such that a class can do many different things. You can also use a class in a singular way. For example, a class can contain functionality, data, relationships, conform to an interchangeable structure, be a function, unite with other classes through inheritance, and more. On the other hand, you could use a class to simply contain data and that is it. You could just use a class to contain functionality. There are many strategies involving classes. Entire books are written on them. What I refer to here is using a class to either contain data, contain functionality, or both.
The parts of a program flow may eventually see representation in C++ as overall modules in which each module (class) is the primary or sole gateway to other classes that collectively work together to implement the overall functionality and data translation role of the overall module that accesses them. Organizing a program to match the program flow document is not required but can often align the perspective described in the flow to represented C++ (or other implementation language) representation. When your thoughts are clear and you have a very good sense of how the program should work, coordinating the program flow and the C++ implementation is yet another way to streamline the effort of creating the program.
The implementation approach you use can be your preference. As I mentioned earlier, many books exist on implementation details such as object-oriented approaches, functional approaches, structured programming, and component architecture. It is totally acceptable to align your program flow to the approach you intend to take. The main recommendation is to keep the program flow general in nature and not rush into the intricacies of the implementation without a general guide.