Design Representations

Where this helps: designing a solution on paper before you write code. In the IB Computer Science Internal Assessment this is Criterion C (the design model). The skill of choosing the right diagram applies to any project.

Table of Contents

  1. Why This Page Exists
  2. The Five Representations
    1. 1. Flowchart: the logic of one process
    2. 2. Data Flow Diagram (DFD): how data moves
    3. 3. Structure chart: how the program breaks into parts
    4. 4. Data dictionary: the precise definition of each data item
    5. 5. UML class diagram: how objects relate
  3. Choosing the Right Representation
  4. Worked Example: Designing a Library Loan System
  5. Quick Check
  6. Match the Representation
  7. Practice Exercises
    1. Core
    2. Extension
    3. Challenge
  8. Connections

Why This Page Exists

Once you know what to build, you design it before you build it. Designing on paper is far cheaper than designing in code: you can throw away a diagram in seconds, but ripping out a half-written program hurts.

There is no single “design diagram”. There are several, and each shows a different view of a system. A flowchart shows the logic of one process; a data flow diagram shows how information moves; a class diagram shows how objects relate. The skill this page teaches is not how to draw all five perfectly. It is knowing which one to reach for, because using the wrong representation is like bringing a map when you needed a recipe.

The Five Representations

1. Flowchart: the logic of one process

A flowchart shows the step-by-step logic of a single process or algorithm: the sequence, the decisions, the loops. It answers “what happens, in what order, and where do the branches go?”

flowchart TD
    A([Start]) --> B[/"Read book barcode"/]
    B --> C{"Book on loan?"}
    C -- Yes --> D[/"Show 'already out'"/]
    C -- No --> E["Mark book as on loan"]
    E --> F([End])
    D --> F

Reach for it when you need to design or explain the internal logic of one task: how a login check works, how a search runs, how a single button behaves.

2. Data Flow Diagram (DFD): how data moves

A data flow diagram shows how information moves through a whole system: where it comes from, what processes change it, and where it is stored. It uses four elements: external entities (people or systems outside), processes (things that transform data), data stores (where data rests), and data flows (the arrows).

flowchart LR
    M(["Member"]) -->|"borrow request"| P["Process:<br/>Issue Loan"]
    P -->|"loan record"| DS[("Loans store")]
    P -->|"updated status"| DB[("Books store")]
    P -->|"receipt"| M

Reach for it when you want the big picture of data, not code logic: what information the system holds, where it flows, and which processes touch it. A DFD deliberately hides how each process works, so you can see the whole system at once.

3. Structure chart: how the program breaks into parts

A structure chart shows the hierarchy of a program: how it decomposes into modules and sub-modules, and which parts call which. It is decomposition drawn as a tree.

flowchart TD
    A["Library System"] --> B["Manage Loans"]
    A --> C["Manage Members"]
    A --> D["Reports"]
    B --> B1["Issue Loan"]
    B --> B2["Return Book"]
    D --> D1["Overdue Report"]

Reach for it when you are planning how to split a program into manageable pieces, and want to see the overall shape before writing any one part.

4. Data dictionary: the precise definition of each data item

A data dictionary is not a diagram at all. It is a table that defines every piece of data the system stores: its name, type, size, allowed values, and meaning. It is the reference that keeps everyone (and every part of the code) agreeing on exactly what “member ID” or “fee” means.

Field Type Size Validation Description
member_id string 6 exactly 6 characters, starts with “M” Unique member identifier
name string 40 not empty Member’s full name
join_date date – not in the future Date the member joined
fine_owed decimal – 0 or greater Money currently owed

Reach for it when you need to pin down the data precisely: the exact fields, types, and validation rules. It is what turns a vague “store the member’s details” into something you can actually build and validate.

5. UML class diagram: how objects relate

A UML class diagram shows the classes in an object-oriented design: each class with its attributes and methods, and the relationships between classes (which owns which, which inherits from which). See OOP for the full treatment.

classDiagram
    class Book {
        -String title
        -boolean onLoan
        +borrow()
        +returnBook()
    }
    class Member {
        -String memberId
        -String name
        +requestLoan()
    }
    Member --> Book : borrows

Reach for it when your solution is built from objects and you need to show their attributes, methods, and relationships. If your program has no classes, a class diagram has nothing to show.

Choosing the Right Representation

This is the heart of the page. Match the question you are trying to answer to the representation that answers it.

If you need to show… Use a…
The step-by-step logic of one process or algorithm Flowchart
How data moves through the whole system Data flow diagram
How the program breaks into modules and sub-tasks Structure chart
The exact fields, types, and validation of stored data Data dictionary
The classes, their attributes and methods, and how objects relate UML class diagram

Real designs use several representations together, because a system has more than one thing worth showing. For the library system above, you might use a DFD for the whole system, a flowchart for the tricky “issue loan” logic, a data dictionary for the member and book records, and a class diagram if the code is object-oriented. The point is to pick each one on purpose.

The most common mistake is using the wrong tool for the question. A flowchart cannot sensibly show where data is stored across a system (that is a DFD). A class diagram is pointless for a short script with no classes (use a flowchart). Before you draw, ask what question the diagram is meant to answer.

Worked Example: Designing a Library Loan System

Scenario. You are designing a small system for a school library: members borrow and return books, and staff can run an overdue-books report.

Here is how you would choose representations for the different design questions:

  • “What information does the system hold, and how does it move?” Draw a DFD: members and staff as external entities, “issue loan” and “return book” as processes, and books, members, and loans as data stores.
  • “Exactly what does a member record contain?” Write a data dictionary for the member and book records, so the fields and their validation are unambiguous.
  • “How does issuing a loan actually work, step by step?” Draw a flowchart for that one process, including the decision “is this book already on loan?”.
  • “How does the whole program break into parts?” Draw a structure chart so you can build and test one module at a time.
  • “If I build it with objects, how do they relate?” Draw a UML class diagram for Book, Member, and Loan.

No single diagram answers all five questions. Choosing the right one for each is the design skill.

Quick Check

Q1. Which representation is designed to show how data moves through a whole system?

Q2. You need to define exactly what a member record contains: each field, its type, size, and validation rule. Which representation fits best?

Q3. You want to design the internal logic of the "issue a loan" process, including the check "is this book already on loan?". Which representation fits best?

Q4. A structure chart is used to show:

Q5. Why is a UML class diagram a poor choice for a short script that uses no classes or objects?

Q6. What is the best approach to representing a real system's design?

Match the Representation

For each design question, name the representation you would use.

Fill in the blanks with one of: flowchart, DFD, structure chart, data dictionary, class diagram.

// Show the exact fields and validation of a "product" record
// Use a: 

// Show how an order's data moves from customer to warehouse to invoice
// Use a: 

// Show the decision logic for validating a password
// Use a: 

// Show how the Order, Customer, and Product classes relate
// Use a: 

// Show how the program splits into modules and sub-modules
// Use a:

Practice Exercises

Note for IB CS learners: these mirror the design thinking behind Internal Assessment Criterion C. Command terms and a suggested mark weight are shown. At least one asks for a full prose response.

Core

  1. State (5 marks) – For each representation (flowchart, DFD, structure chart, data dictionary, class diagram), state in one sentence what it is best used to show.

  2. Apply (4 marks) – For a cinema ticket-booking system, name the representation you would use to answer each question: (a) how does choosing a seat work step by step? (b) what fields does a booking record contain?

  3. Draw (4 marks) – Draw a data dictionary (at least four fields) for a “student” record in a homework-tracking app, including a validation rule for each field.

Extension

  1. Draw (6 marks) – Draw a flowchart for the logic of returning a library book, including the check for whether the book is overdue and, if so, calculating a fine.

  2. Apply (6 marks) – For an online food-ordering system, choose three different representations and explain, for each, which specific design question it answers that the others do not.

Challenge

  1. Justify (8 marks) – A student designs an entire system using only flowcharts. Explain what important design information this leaves out, and justify which additional representations would strengthen the design and why. (Write in prose.)

Connections

  • Prerequisite: Requirements Gathering – you design against the requirements you gathered
  • Related: Flowcharts – the full treatment of one representation
  • Related: OOP – where UML class diagrams come from
  • Next: Testing Strategy – once designed and built, you test it deliberately
  • Related: Internal Assessment – the design model is assessed in Criterion C

© EduCS.me — A resource hub for Computer Science education

This site uses Just the Docs, a documentation theme for Jekyll.