Some problems are very complex. Some can be quiet simple. Regardless, we often need to define our solution, as part of our problem solving steps, in order to make sure our solution will work. A flowchart is a graphical way to show the logic of an algorithm.
In programming, we often talk about algorithms, but in reality there is nothing mystical about them. They are merely a step of steps that are taken to accomplish a given task. Notice that while this often entails programming, it doesn’t technically have to.
The simplest of these is to have a series of steps follow a linear sequence. Step one is then followed by step two then step three, etc until we complete the series of tasks.
In this simple form we can programmatically create batch applications. They are often used by IT professionals to perform a series of tasks after hours when the system(s) are not in use. It could be fairly simple with only a single step or two, two very complex and composed of dozens of steps. In my career, I’ve developed numerous applications like this, that in reality are little more than a series or commands that get run every evening, or once a week, or even once a month.
An example of what a batch program, or series of batch programs might look like would be:
- Deactivate users from list From Deactivated Employees in Servers
- Backup Server 1
- Backup Server 2… etc
- Copy Data from Accounting Software to CRM
- Copy Data from ERP to CRM
- Copy New Employees from HR to Training
- etc…
Each of these can have multiple steps, and depending upon the size of the company and how complex their systems are. A company I worked for, we had numerous servers between accounting, delivery, customer support, sales, hr, training, and product development, each system had to share some data with other systems, but not all the data. We had to back up servers, databases, and users/permissions, and much, much more.
Of course, that is not where we start. So let’s look at the simplest possible starting point, and go on from there.
A Simple Linear Process
While this is a super simple example, it does introduce us to several factors and symbols, both within the app Lucid Chart, as well as within Flowcharts in general.
Terminal / Terminators
Terminals, or Terminators the names are interchangeable, are used to define the beginning and end points of your flowchart. Inside of them, we often write Start and Stop, just to make sure we are as clear as possible.
Every flowchart should have two, one start and one stop. However, you may see more than one stop in many cases (but we try not to, and you shouldn’t in this class).
Data IO Or Input/Output Box
This symbol is used to get input and give output to your application. We’ll often put input/output/print/or something similar to give people a chance to understand what is occurring.
This can be a little confusing as it is used for both input and output, which is why we label them.
Flow Lines
Flow lines are used to show how the application/logic moves from one symbol to another. It ensures that the logic of the application is easy to follow.
But Why
So why do we create flowcharts. Well there are a couple of reasons.
Flowcharts are extremely visual. It makes it easy to see what you where you start and where you go along the way. You can literally trace the steps with your finger by following the flow lines.
Next, we need ways to communicate with non-technical people. This is a great way to do so. Anyone can follow a flowchart, even if it doesn’t follow our exact method. Flowcharts can be used for application planning, but also for other logical steps.
This is a great example of a “flowchart” which isn’t. Yet, without a lot of effort, you can start to figure out what a person needs to do in order to work through the flow chart.
More Complicated Examples
Of course, flowcharts can get a lot more complicated as well. We’ll look at another example here. But we’re not going to jump straight too the hard stuff. Instead, we’ll move one step at a time.
Linear Steps to Problem Solving was originally found on Access 2 Learn
