Flowcharts and Pseudocode

Flowcharts and Pseudocode

Module Three asks you to represent the same paycheck-calculator design in two forms:

• a flowchart; and
• pseudocode.

Both are design tools. Neither is Python code.

This page explains the tools without giving you a completed paycheck solution.

Why Use Two Representations?

Different representations reveal different kinds of design problems.

A flowchart makes it easier to see:

• sequence;
• branches;
• where paths split;
• where paths rejoin; and
• whether a path accidentally goes nowhere.

Pseudocode makes it easier to see:

• detailed order;
• variables or values involved;
• calculations;
• indentation; and
• which statements belong to a branch.

If the two designs disagree, the disagreement is useful evidence that the logic needs another review.

Flowchart Symbols Required by the Assignment

The Module Three assignment specifically calls for appropriate symbols and arrows for:

• Start and end points
• Input and output
• Decision branching
• Processing steps

The provided Draw.io template includes a Symbols tab you can use as a reference.

Start / End

A terminator symbol marks where the algorithm begins or ends.

A reader should be able to identify one clear starting point and follow the arrows until the solution ends.

Input / Output

An input/output symbol represents information entering or leaving the program.

For a generic example:

INPUT value

or

OUTPUT result

Use your assignment requirements to determine what the actual paycheck design needs.

Processing

A process symbol represents work such as a calculation or assignment.

Generic example:

Calculate total from known values

Do not use the shape merely as a box around every piece of text. The symbol communicates that processing occurs at that point.

Decision

A decision symbol asks a question that creates different possible paths.

Generic example:

condition true?

The outgoing arrows should make the alternatives clear, commonly with labels such as Yes/No or True/False.

Every branch needs somewhere to go.

Arrows Matter

Flowchart arrows show execution order.

When reviewing your chart, follow the arrows literally. Do not assume a reader will guess the intended next step because two shapes happen to be close together.

Check:

• every required step has an incoming path when appropriate;
• every non-End step has a next step;
• each decision has all needed outgoing paths; and
• every possible path eventually reaches End.

Pseudocode Is Structured Logic

Pseudocode describes an algorithm in human-readable steps without requiring exact Python syntax.

A generic structure might look like:

BEGIN example
    INPUT value

    IF condition THEN
        LET result = processing_for_one_case
    ELSE
        LET result = processing_for_other_case
    ENDIF

    OUTPUT result
END example

This example demonstrates structure only. It does not provide the paycheck condition or paycheck calculations.

Indentation Communicates Membership

Indentation helps a reader see which statements belong inside a branch.

Compare:

IF condition THEN
    PROCESS one_case
ELSE
    PROCESS other_case
ENDIF

The indented lines visually belong to the branch above them.

This same idea will matter when you later write Python, where indentation is part of the language syntax.

Keywords Make Intent Clear

The assignment suggests pseudocode keywords such as:

• IF
• ELSE
• LET

Your starter also suggests keywords such as INPUT and OUTPUT because they make the design easier to read.

Use keywords consistently. The goal is clear logic, not memorizing one universal pseudocode language.

Branching Must Cover the Required Cases

The paycheck requirements describe two pay-rule cases separated by a boundary.

Your design needs a decision structure that accounts for all values covered by those rules.

The repository deliberately does not tell you which exact comparison operator to write. Use your Analyze work and the wording first 40 hours versus above 40 hours to create and verify your own condition.

Compare the Two Designs Side by Side

After both are complete, ask:

• Do they obtain the same input?
• Do they make the same decision?
• Do the corresponding branches perform the same work?
• Do they treat exactly 40 hours the same way?
• Do they produce the same result?
• Do they output the same required information?

If the answer to any question is no, revise the design before submitting.

Trace a Case

You can test design logic without Python.

1. Choose a verification case from the SRS.
2. Follow that value through the flowchart.
3. Record the expected result.
4. Follow the same value through the pseudocode.
5. Compare the paths and result.

Try a boundary case as well as an ordinary case.

Common Design Problems to Look For

Without giving away the solution, common structural problems include:

• using the wrong symbol type;
• missing arrows;
• a decision path that does not continue;
• pseudocode with inconsistent indentation;
• one artifact containing logic missing from the other;
• accidentally treating the boundary differently in the two artifacts; and
• adding input-validation or formatting requirements that the assignment never states.

Before Submission

Use the checklist in design/README.md and the current D2L rubric. GitHub Assignment Checks can verify file structure and starter completion state, but they cannot judge whether the design logic deserves a particular grade.

Return to Home or continue to Working in Your Course IDE.