Dragon Ball Lunch: Design a Connected Lunch-Ordering Program
> Project context: Students design a fictional lunch-ordering program inspired by Dragon Ball characters. Use character names or images only if permitted by school policy; students may instead invent original characters. The project focuses on how a networked system sends, receives, and responds to information—not on using a real ordering service or collecting personal data.
Learning Objectives
By the end of the project, students will be able to:
1. Describe how a client device, network, and server work together to send a lunch choice and return a response, using a labeled diagram with at least three correctly identified parts.
2. Create a block-based or unplugged algorithm that accepts a lunch choice, checks whether it is valid, and produces an appropriate response.
3. Test and debug the program using at least three test cases, identify a problem, and document a correction.
4. Explain how their design protects information by collecting only what is needed and avoiding personal or sensitive data.
Standards Alignment
Standards are paraphrased for planning. Confirm exact wording and grade-band expectations in the version adopted by your state or district.
| Framework | Alignment |
|---|---|
| CSTA K–12 Computer Science Standards: Networks and the Internet, Grades 3–5 | Students develop an age-appropriate understanding of how information moves between devices and how networks support communication. The project models a device sending a lunch choice to a server and receiving a response. |
| CSTA K–12 Computer Science Standards: Algorithms and Programming, Grades 3–5 | Students create and test a program using sequences, conditionals, inputs, and outputs; they identify and correct errors. |
| ISTE Student Standard 1.4: Innovative Designer | Students use a design process to develop, test, and improve a solution to a defined problem. |
| ISTE Student Standard 1.5: Computational Thinker | Students break a problem into steps, create a solution, and test or refine it using data from trials. |
| ISTE Student Standard 1.6: Creative Communicator | Students communicate their solution using a diagram, program, demonstration, or explanation appropriate to the audience. |
| State or district adaptation | Map the objectives to local computer science standards for networking, algorithms, programming, testing, and digital citizenship. This plan is designed to be adaptable and does not assume one state’s terminology. |
Materials and Preparation
- Student devices with a block-based programming tool, such as Scratch, or paper, cards, and markers for an unplugged version
- Projector or interactive display
- Network-path diagram or board space
- Lunch menu cards with fictional choices, such as Saiyan Power Bowl, Capsule Corp. Crunch Wrap, and Senzu Fruit Cup
- Input, output, and error-message cards
- Testing checklist and project rubric
- Optional character pictures or student-created original characters
- No student names, passwords, addresses, or other personal information are needed
Teacher preparation: Prepare a sample client–network–server diagram and a simple demonstration program. Ensure that students can complete the project without creating accounts or sharing information online.
Key Vocabulary
| Term | Student-friendly meaning |
|---|---|
| Network | Connected devices that can send information to one another |
| Client | A device or program that requests information or a service |
| Server | A computer or program that receives requests and sends responses |
| Input | Information entered or sent to a program |
| Output | Information a program displays or sends back |
| Algorithm | A set of ordered steps for solving a problem |
| Conditional | A rule that tells a program what to do when a condition is met |
| Debugging | Finding and correcting a problem in a program |
| Test case | A specific input used to check whether a program works as expected |
| Privacy | Keeping personal information safe and sharing only what is necessary |
Project Challenge
Students work as a class to design a model lunch-ordering system. In teams, they create a program or paper prototype that:
1. Shows a fictional lunch menu.
2. Accepts a choice.
3. Checks whether the choice is on the menu.
4. Sends the choice from a client to a modeled server.
5. Returns a confirmation or a helpful error message.
6. Uses no personal information.
Success Criteria
A successful project:
- Shows the client, network, and server in a diagram or demonstration.
- Uses a clear sequence and a conditional.
- Gives an appropriate response to both a valid and an invalid choice.
- Passes at least three test cases, including one invalid input.
- Includes a documented debugging improvement.
- Avoids collecting personal or sensitive information.
Timed Instructional Sequence
Day 1: Understand the Problem and Model the Network — 45 minutes
| Time | Teacher and student actions | Formative check |
|---|---|---|
| 0–5 min | Introduce the essential question and project challenge. Show the fictional menu. Ask: “What information would the ordering program need, and what should it not ask for?” | Listen for the distinction between a lunch choice and personal information. |
| 5–12 min | Teach client, network, and server with a simple diagram. Model a request traveling from a device to a server and a response returning. | Students point to or name each part in a quick diagram check. |
| 12–20 min | Whole-class “message journey”: a student sends a menu choice card as the client; classmates pass it along the network route to the server; the server returns a confirmation or error card. | Ask students to explain what each role did. Correct misconceptions immediately. |
| 20–30 min | In teams, students sketch a lunch-ordering system and label the client, network, server, input, and output. | Review diagrams using a brief checklist; prompt teams to clarify missing labels. |
| 30–40 min | Teams write the algorithm in plain language: display menu → receive choice → check choice → return response. | Ask teams to predict what happens when a choice is not on the menu. |
| 40–45 min | Closure: students complete an exit ticket: “The client sends ____. The server returns ____. One thing the system should not collect is ____.” | Use responses to plan Day 2 reteaching. |
Day 2: Program the System — 45 minutes
| Time | Teacher and student actions | Formative check |
|---|---|---|
| 0–5 min | Review the network diagram and algorithm. Revisit the privacy rule: collect only the lunch choice needed for the demonstration. | Cold-call or invite volunteers to describe the request and response. |
| 5–12 min | Model a short program in blocks or pseudocode. Demonstrate an input, a conditional, a confirmation, and an error message. | Students predict the output for a valid and invalid choice. |
| 12–30 min | Teams build their program or paper prototype. Suggested logic: “If the choice matches a menu item, confirm it; otherwise, show the menu and ask again.” | Circulate with a checklist: input present, conditional present, both response paths present. |
| 30–38 min | Teams exchange programs or prototypes. The partner team tries the system and records what happens. | Check whether testers use the program as intended and report specific issues. |
| 38–45 min | Teams select one issue to debug. They record what happened, what they expected, and what they changed. | Review debugging notes for evidence of a test and a correction. |
Day 3: Test, Improve, and Present — 45 minutes
| Time | Teacher and student actions | Formative check |
|---|---|---|
| 0–5 min | Review success criteria and test-case expectations. | Students name one test the system must pass. |
| 5–18 min | Teams run at least three test cases: a valid first choice, another valid choice, and an invalid choice. They record expected and actual results. | Teacher checks that test cases include both valid and invalid inputs. |
| 18–25 min | Teams debug and retest at least one issue. | Ask: “What evidence shows your change improved the program?” |
| 25–38 min | Teams present their network diagram and demonstrate the program or prototype. They explain one test, one bug, and one fix. | Use the performance rubric below. |
| 38–45 min | Individual reflection and closure: students answer, “How does information travel through your system? What did you debug? How did you protect privacy?” | Collect reflections to assess individual understanding. |
Sample Algorithm
```text
Display the fictional lunch menu.
Ask the user to choose a menu item.
Send the choice from the client to the modeled server.
If the choice matches a menu item:
Display “Your fictional order is confirmed.”
Otherwise:
Display “That choice is not on the menu. Please try again.”
Do not ask for a name, password, address, or other personal information.
```
Assessment
Formative Assessment
Use these checks throughout the project:
- Exit ticket identifying client, server, request, and response
- Labeled network diagram
- Algorithm review before programming
- Teacher observation checklist during construction
- Peer test notes showing expected and actual results
- Debugging record describing a problem and correction
- Individual reflection to distinguish personal understanding from team output
Summative Performance Assessment
Students submit or present:
1. A labeled client–network–server diagram.
2. A working block-based program or paper prototype.
3. A record of at least three test cases, including an invalid input.
4. A debugging note explaining one problem and how it was corrected.
5. An explanation of how the design avoids unnecessary personal information.
Performance Rubric
| Criteria | 4 — Strong | 3 — Meets | 2 — Developing | 1 — Beginning |
|---|---|---|---|---|
| Network model | Clearly explains and labels client, network, server, request, and response. | Correctly labels client, network, and server and describes the request and response. | Labels some parts but confuses their roles or the information flow. | Diagram or explanation is incomplete or mostly inaccurate. |
| Program logic | Uses a clear sequence and conditional; valid and invalid inputs receive appropriate responses. | Uses a sequence and conditional; both response paths generally work. | Some logic is present, but one response path is missing or unreliable. | Program or prototype does not yet show a usable sequence. |
| Testing and debugging | Tests three or more cases, records results, and explains a successful improvement. | Tests three cases and records at least one correction. | Tests fewer than three cases or gives limited evidence of debugging. | Provides little or no testing or debugging evidence. |
| Privacy and communication | Clearly explains data minimization and presents the design so others can follow it. | Avoids personal data and communicates the main design. | Needs reminders about privacy or provides an unclear explanation. | Includes unnecessary personal data or cannot explain the design. |
Differentiation and UDL Supports
- Multiple means of representation: Teach network flow with a diagram, spoken explanation, role-play, and written vocabulary cards. Provide a sample program and a visual algorithm.
- Multiple means of action and expression: Allow students to demonstrate learning with block-based code, pseudocode, a paper prototype, a labeled diagram, or an oral explanation.
- Multiple means of engagement: Let teams choose menu items, visual themes, or original characters while keeping the network and programming requirements consistent.
- For students needing additional support: Provide sentence frames, a partially completed diagram, a menu limited to two choices, and an algorithm with blanks to fill in. Pair students strategically and check in after each step.
- For multilingual learners: Preteach vocabulary with visuals and gestures; offer bilingual glossaries if available; allow rehearsal with a partner before presenting; assess computer science understanding separately from English fluency.
- For students with disabilities: Provide accessible devices and input options, screen-reader-compatible materials where possible, high-contrast visuals, enlarged text, keyboard alternatives, reduced copying demands, and additional processing time as specified in the student’s plan.
- For students ready for extension: Add a “sold out” condition, a retry limit, or a server-status message. Have students explain how the system responds when a network message is delayed or lost, without requiring an actual online connection.
Accommodations and Classroom Management
- Follow each student’s IEP, 504 plan, and school accessibility procedures.
- Offer flexible roles such as programmer, diagram designer, tester, or presenter; rotate roles when practical.
- Provide printed instructions and a visible timer for students who benefit from predictable steps.
- Use fictional data only. Do not enter real student orders, names, or account credentials into the program.
- For whole-class discussion, use think time and multiple response options, such as speaking, writing, pointing, or using a response card.
Family and Community Connections
Invite students to ask a family member how a real service—such as a library catalog, school website, or food-ordering system—might receive a request and return information. Students should describe the process generally and must not share account details, private information, or screenshots. If appropriate, invite a school technology staff member to explain how school devices communicate safely on a network.
Teacher Reflection and Closure
After the lesson, reflect on:
- Could students explain the path from client to server and back?
- Did the program include a meaningful conditional and a useful response to invalid input?
- Were students able to test systematically and identify a bug using evidence?
- Did the fictional context support engagement without distracting from networking and debugging?
- Which students need additional practice with network roles, conditionals, or test cases?
- What adjustment
