Theory
Two views of your design
Design is clearest when you can draw it. Two diagrams complete your project's design and communicate it to your team and evaluators: a data flow diagram and an architecture diagram. They show two different, complementary views.
A data flow diagram (DFD) shows how data moves through the system. An architecture diagram shows the components and how they connect. One traces the information; the other maps the structure. This closing lesson of the design unit explains both, so your design is documented visually, which is far easier to understand, and to present, than paragraphs of text. A good diagram is worth a thousand words.
Theory
Data flow diagram: where data goes
A data flow diagram (DFD) answers: where does data come from, what happens to it, and where does it go? It has four elements:
External entities (sources or destinations of data, like a student), processes (that transform data, like 'register student'), data stores (where data is kept, like the registrations database), and data flows (arrows showing data moving between them).
DFDs come in levels: a context diagram (level 0) shows the whole system as a single process with its external entities, then lower levels break it into more detail. A DFD makes the movement of information through your system explicit, which helps you spot missing steps or unclear handling of data. It traces the data's journey.
Theory
Architecture diagram: how components connect
An architecture diagram shows the system's technical structure: its major components, front end, back end, database, external services (like a payment gateway or Firebase), and how they connect and communicate.
Where the DFD follows the data, the architecture diagram shows the building blocks and their wiring: 'the Angular front end talks to the Express backend, which reads and writes the MongoDB database and calls the Firebase auth service'. It gives everyone a clear picture of the system's shape and the technologies in each part.
Together, the DFD (data movement) and the architecture diagram (component structure) document your design from two angles, and both are valuable in your project report and presentation, where a clear diagram communicates your design instantly.
Quiz
What is the main difference between a data flow diagram (DFD) and an architecture diagram?
- They are the same diagram with different names
- A DFD shows how data moves through the system (sources, processes, stores, flows), while an architecture diagram shows the system's components and how they connect
- A DFD shows the UI colours; an architecture diagram shows the database rows
- Neither is useful for a project
Show the answer
A DFD shows how data moves through the system (sources, processes, stores, flows), while an architecture diagram shows the system's components and how they connect
A data flow diagram (DFD) shows how DATA MOVES through the system, its external entities, processes, data stores, and the flows between them, while an architecture diagram shows the system's COMPONENTS (front end, back end, database, external services) and how they connect. Option A is wrong: they are distinct, complementary views (data movement vs component structure). Option C is wrong on both: DFDs are not about UI colours, and architecture diagrams are not about database rows; both are higher-level design views. Option D is wrong: both are valuable for planning and for documenting/presenting the design. In short: DFD follows the data; architecture maps the components.
Think first
Why express your design in diagrams rather than just describing it in words?
Why draw DFDs and architecture diagrams instead of writing a text description of the design? Then tap.
Show the answer
Because diagrams communicate structure and relationships FAR more clearly and quickly than prose, so they help your team build the right thing, help evaluators understand your design at a glance, and even help you catch flaws, achieving in one picture what pages of text struggle to convey. Software design is fundamentally about STRUCTURE, how parts connect, how data moves, how components relate, and structure is inherently spatial and relational, which is exactly what diagrams are good at showing. Try describing in words how five components connect and how data flows between them: the reader must hold many relationships in their head and reconstruct the shape mentally, which is slow and error-prone. A diagram shows all those relationships SIMULTANEOUSLY and visually, so anyone can see the whole structure and any specific connection instantly. This has several concrete payoffs. For your TEAM, a shared diagram gives everyone the same clear mental model, so they build parts that fit together, rather than each interpreting a wordy description differently. For EVALUATORS (the panel reading your report and watching your presentation), a clean DFD or architecture diagram lets them grasp your system's design immediately and see that you thought it through, which is far more persuasive than dense paragraphs they must decode. For YOU, the act of drawing the design often EXPOSES problems, a missing data store, an unclear flow, a component with too many connections, that were hidden in vague prose; the discipline of making it fit on a diagram forces clarity. Diagrams are also the standard, expected way to document software design, so producing them shows professionalism. This is why 'a picture is worth a thousand words' is especially true for system design: the DFD and architecture diagram turn your design into something instantly understandable and checkable. So draw your design, do not just describe it, because the clarity a diagram provides benefits everyone who needs to understand, build, or assess your project. Show the structure visually, and it communicates in a way words cannot.
Summary
Key takeaways
- Two diagrams complete and communicate your project's design: a data flow diagram and an architecture diagram.
- A data flow diagram (DFD) shows how data moves: external entities (sources/destinations), processes (transform data), data stores (hold data), and data flows (arrows).
- DFDs have levels: a context diagram (the whole system as one process) then more detailed levels.
- An architecture diagram shows the system's components (front end, back end, database, external services) and how they connect and communicate.
- The DFD follows the data's journey; the architecture diagram maps the component structure.
- Both document the design clearly and are valuable in your report and presentation.
- Memory hook: DFD shows data movement, architecture diagram shows component structure, draw your design, do not just describe it.