NATURE OF PROGRAMMING LANGUAGES

ON THIS PAGE
SECTION 1 | WHAT ARE FLOWCAHRTS
SECTION 2 | CREATING FLOWCHARTS
SECTION 3 | TRACING FLOWCHARTS
SECTION 4 | EXAMPLE EXAMINATION STYLE QUESTION - COMING SOON

ALSO IN THIS TOPIC
THINKING PROCEDURALLY
THINKING LOGICALLY
THINKING AHEAD
THINKING CONCURRENTLY​ 
 THINKING ABSTRACTLY
 YOU ARE HERE | FLOWCHARTS
MORE COMING SOON

SECTION 1 | WHAT ARE FLOWCHARTS​​

​Flowcharts are a diagram that represents a process. They trace the steps of the process and included decisions and branches that the process might take. They are frequently used in the design stage of a product and are a useful tool to document and represent how a process or algorithm should flow or work.

Flowcharts use different symbols to represent various actions, for example a diamond shape represents a decision in the process and will always have 2 possible outcomes which can be represented with YES or NO. whereas a parallelogram represents Data in flowchart. The image below shows many symbols that are used in flowcharts, however many of these are not used at GCSE, IB and A-level Computer Science. Commonly used symbols are discussed later.

SECTION 2 | CREATING FLOWCHARTS

Creating effective flowcharts is essential for conveying processes, algorithms, or workflows clearly and concisely. Here are some tips to help you create clear, readable, and effective flowcharts.

Start Simple: Begin with a basic idea or process before adding details. Understand the start and end points of your flowchart first.
Use Consistent Shapes: Familiarize yourself with standard flowchart symbols:

• Ovals for "Start" and "End".
• Rectangles for processes or actions.
• Diamonds for decision-making points.
• Parallelograms for inputs or outputs.
• Always use these symbols consistently.

Maintain Flow Direction: Typically, flowcharts flow from top to bottom or left to right. Keep a consistent direction unless there's a compelling reason not to.
Avoid Overcrowding: Ensure your flowchart is clear and easy to read. If it becomes too detailed or complex, consider breaking it into multiple flowcharts or using a sub-process symbol.
Use Arrows Wisely: Arrows guide the viewer and indicate the direction of flow. Make sure they don’t cross over each other too often, as this can make the chart confusing.
Label Clearly: Every shape and decision point should have clear, concise text. Avoid using jargon unless it's widely understood by your target audience.
Test Your Flowchart: Walk through your flowchart as if you're following the process or algorithm it represents. This will help you catch any logical errors or missing steps.
Use Colours: Different colours can represent different types of actions or highlight particular pathways through the flowchart. But use them sparingly and consistently!
Get Feedback: Sometimes you're too close to a project to see errors or ambiguities. Having another set of eyes review your flowchart can be invaluable.

SECTION 3 | TRACING FLOWCHARTS

A trace table, sometimes called a dry run table, is a technique used to test algorithms for correctness and understand their behaviour. It's essentially a table that keeps track of the changes in variable values as you progress through an algorithm or flowchart step by step.

HOW TO CREATE A TRACE TABLE
Initialize Columns for Variables

• Create a column for each variable and each output used in your flowchart or algorithm.
• You might also want a column for the process or action name, so you know which step you're recording.

Starting Values

• At the start of your trace, initialize the variables with their starting values on the first row of your table.

Process Each Step

• For each step in the flowchart or algorithm, update the values in your trace table to show any changes that occurred.

Keep Track of Loops

• If there's a loop in your flowchart or algorithm, ensure that each iteration of the loop has its row(s) in the trace table.

WHEN TO DROP TO THE NEXT ROW IN YOUR TRACE TABLE

When tracing an algorithm or flowchart using a trace table it can be confusing when to drop to a new row in your trace table, you generally drop down to a new line in the table under the following circumstances:

New Iteration or Step

• Each time you progress to a new step or action in your algorithm or flowchart, you start a new line. This helps in mapping each step to its corresponding effect on the variables.

Loop Iteration

• When your algorithm or flowchart contains a loop (like a "for" or "while" loop), you start a new line for each iteration of the loop. This is crucial to track how variable values change with every pass of the loop.

Decision Branching

• When you encounter a decision point (usually a conditional like "if" or "else"), and you take a branch based on a condition, you might opt to use a new line to indicate the branch you've taken, especially if different branches affect variables differently.

Function or Procedure Calls

• If your flowchart or algorithm involves calling a function or procedure, every time the function is called, you might start a new line, especially if it impacts the variables you're tracing.

Revisiting a Previous Step

• If, for any reason, you're going back to a previous step or action in your algorithm or flowchart (not including regular loop iterations), this might warrant a new line in the trace table.

Changes in Variables

• If any variable changes its value, even if you're in the same step, you should consider dropping to the next line to clearly represent the state change.

Special Events or Errors

• If you encounter an unusual event, an error, or an exception while tracing, it's a good idea to record this on a new line with a clear note about what occurred.

Remember, the primary goal of the trace table is clarity. When in doubt, it is generally a good idea to start a new line in the trace table to ensure each step or change is clearly documented and do not be afraid to make comments for the examiner to see your logic, they should be marking from a correct solution.

SECTION 4 | EXAMPLE EXAMINATION STYLE QUESTION

At IB level the specification states that you will not be required to draw a flowchart, but understanding and tracing then is something that frequently come up in examination papers.

Task: Prime Number Checker Flowchart Creation

OBJECTIVE
Create a flowchart that describes an algorithm to determine whether a given input number (N) is a prime number.

BRIEF
A prime number is a natural number greater than 1 that is not a product of two smaller natural numbers. Your task is to develop a flowchart that elucidates the logical flow of an algorithm, which takes a single input (N) and outputs whether it is a prime number or not.

Bullet-Point Steps to Identify a Prime Number

1: Start
Begin the flowchart and algorithm.

2: Input Number (N)
Obtain the number that you need to check.

3: Initial Check
If N is less than or equal to 1, it is not prime. End.
If N equals 2, it is prime. End.
If N is even (N mod 2 equals 0), it is not prime. End.

4: Initialize Counter (i) to 3
As you have already checked for 2, you start checking for divisibility from 3.
Loop Start (While i <= square root of N):
Creating a loop that runs while i is less than or equal to the square root of N (this is because a larger factor of N must mean that a smaller one exists, thus, reducing unnecessary computations).

5: Check for Divisibility
If N mod i equals 0, it is not prime. End.

6: Increment Counter
i = i + 2 (Checking only odd numbers, as even numbers would have been caught by the initial check).

7: Prime Confirmation

• If no factors found in the loop, N is prime. End.

Guidelines

• Use appropriate symbols: Use ovals for Start and End, parallelograms for Input/Output, rectangles for processes, and diamonds for decision points.
• Ensure Logical Flow: The arrows should clearly indicate the direction of the logical flow.
• Label Processes and Decisions: Clearly label the processes and decisions happening at each point.
• Be Clear and Concise: Each step should be easy to understand.
• Review and Revise: Check for logical errors or possible simplifications.

NAVIGATION

COMING SOON