Dragon Ball Lunch: Designing a Connected Lunch-Ordering Program
> Project context: Students create a classroom prototype—not a real ordering system. The prototype simulates how a lunch menu could be shared over a network and how a program could respond to a user’s choices. Students should use fictional menu items and avoid collecting names, addresses, or other personal information.
Learning Objectives
By the end of the project, students will be able to:
1. Explain, using a labeled diagram, how a client, a server, and a network can work together to share a lunch menu.
2. Create an algorithm or block-based program that lets a user select a menu item and displays an appropriate response.
3. Test the program with at least three inputs, identify at least one error or unexpected result, and revise the program.
4. Describe one way to protect privacy or make a networked lunch tool safer and more accessible.
5. Present the prototype and explain how its network model and debugging choices support the project goal.
Standards Alignment
Standards are summarized for classroom planning. Check the current CSTA and ISTE documents, along with your state’s adopted standards, when finalizing local alignment.
| Framework | Grade-level connection | How the project addresses it |
|---|---|---|
| CSTA K–12 Computer Science Standards: Networks and the Internet | Grade 3–5 concepts include describing how computing devices connect and communicate, and considering how information is shared across networks. | Students model a user device (client) requesting a menu from a classroom server and receiving a response. They discuss what information should—and should not—be shared. |
| CSTA K–12 Computer Science Standards: Algorithms and Programming | Grade 3–5 concepts include creating programs with sequences, events, loops, and conditionals; testing and debugging; and describing how a program works. | Students build a menu-selection program with input, conditional responses, testing, and revisions. |
| ISTE Student Standard 1.4: Innovative Designer | Students use a design process to solve problems and create useful, imaginative solutions. | Teams plan, build, test, and improve a lunch-menu prototype. |
| ISTE Student Standard 1.5: Computational Thinker | Students use computational methods to develop and test solutions. | Students break the task into steps, use conditions, test inputs, and debug. |
| ISTE Student Standard 1.6: Creative Communicator | Students communicate clearly using digital tools and appropriate formats. | Students demonstrate their prototype and explain its design to classmates. |
| ISTE Student Standard 1.2: Digital Citizen | Students practice safe, responsible, and respectful technology use. | Students avoid collecting personal information and discuss safe sharing and accessibility. |
Materials and Preparation
- Computers or tablets with a block-based coding tool, such as Scratch, or paper-based programming materials
- Projector or interactive display
- Client–network–server diagram or cards labeled Client, Network, and Server
- Student planning sheet, test log, and reflection prompt
- Fictional Dragon Ball–themed menu cards, such as Saiyan Power Bowl, Capsule Corp. Fruit Cup, and Kame House Water
- Optional: printed blocks, sticky notes, colored pencils, and large-print materials
Before the unit: Check device and software access; prepare a working sample or paper alternative; confirm that all menu content is school-appropriate. Do not use real student food preferences, names, or health information in the prototype.
Key Vocabulary
| Term | Student-friendly meaning |
|---|---|
| Network | A connection that lets devices send and receive information. |
| Client | A device or program that requests information, such as a student’s menu screen. |
| Server | A computer or program that provides information when requested. |
| Input | Information a user gives a program, such as choosing a menu item. |
| Output | What a program shows or says in response. |
| Algorithm | A set of steps for solving a problem. |
| Condition | A rule that tells a program what to do in a particular situation. |
| Debugging | Finding and fixing problems in a program. |
| Privacy | Keeping personal information safe and sharing only what is needed. |
Project Description
Students work in small teams to make a prototype that simulates a networked lunch menu. A user selects one of several fictional menu items. The program displays a matching response, such as a description or themed message. Students also create a simple diagram showing how the menu request travels from a client through a network to a server and back.
The prototype may be built in a block-based coding tool or with paper cards and teacher-led simulation. It does not need to connect to the internet or store real information.
Timed Instructional Sequence
Lesson 1: What Does a Network Do? — 45 minutes
| Time | Instruction and student activity | Formative check |
|---|---|---|
| 5 min | Introduce the essential question and project. Ask: “How might a device show a lunch menu that is stored somewhere else?” | Listen for initial ideas about connected devices and shared information. |
| 10 min | Teach client, network, and server using a simple diagram. Model a request and response with labeled cards. | Students point to or name each part in the model. |
| 15 min | Whole-class simulation: one student or group acts as a client, another as a server, and classmates represent the network carrying a menu request and response. | Ask students to explain what travels in each direction. |
| 10 min | Teams sketch a client–network–server diagram for the Dragon Ball lunch menu. | Check that diagrams show a request and a response. |
| 5 min | Exit ticket: “What does the client request, and what does the server send back?” | Use responses to identify concepts to revisit. |
Lesson 2: Plan the Program — 45 minutes
| Time | Instruction and student activity | Formative check |
|---|---|---|
| 5 min | Revisit the project goal and network diagram. | Students name one part of the network model. |
| 10 min | Model an algorithm: show menu choices, receive a selection, check the choice, and display a response. | Students identify the input and output. |
| 15 min | Teams choose three or more fictional menu options and write or arrange their algorithm steps. | Review for clear order and a response for each choice. |
| 10 min | Teams add a plan for an invalid or unrecognized choice, such as “Please choose an item from the menu.” | Ask, “What should the program do if the input does not match a menu item?” |
| 5 min | Students share one planned condition and its response. | Check that students connect the condition to the output. |
Lesson 3: Build the Prototype — 45 minutes
| Time | Instruction and student activity | Formative check |
|---|---|---|
| 5 min | Review safe project rules: use fictional choices and do not enter personal information. | Students restate one privacy rule. |
| 10 min | Demonstrate how to create an input or choice, use a conditional, and display an output in the chosen tool. | Students predict what happens for one sample choice. |
| 20 min | Teams build the program or paper simulation from their algorithm. The teacher conferences with teams. | Check that the program has a menu, input, and at least two matching responses. |
| 5 min | Teams connect their prototype to the network diagram by identifying what the client requests and what the server provides in the simulation. | Ask each team to explain the request and response. |
| 5 min | Save work or organize paper materials and note one question for testing. | Review teams’ readiness to test. |
Lesson 4: Test and Debug — 45 minutes
| Time | Instruction and student activity | Formative check |
|---|---|---|
| 5 min | Model a test: enter a valid choice, observe the output, and compare it with the expected result. | Students identify expected versus actual output. |
| 15 min | Teams test at least three inputs, including a valid choice and an invalid or unexpected choice. They record results. | Review test logs for clear inputs and observations. |
| 15 min | Teams locate at least one bug or confusing behavior and revise their program. If no bug appears, teams improve clarity or test an edge case. | Ask students to explain what they changed and why. |
| 5 min | Peer testing: another team tries the prototype and gives one specific suggestion. | Observe whether feedback is relevant and respectful. |
| 5 min | Teams record the final change they made. | Collect or check the test log. |
Lesson 5: Present and Reflect — 45 minutes
| Time | Instruction and student activity | Formative check |
|---|---|---|
| 5 min | Review presentation expectations and success criteria. | Students identify one feature they will explain. |
| 20 min | Teams demonstrate the menu prototype and network diagram. Each team explains one test and one debugging change. | Use the performance rubric below. |
| 10 min | Class discussion: “What information should a lunch menu tool share? What should it keep private?” | Listen for privacy-aware reasoning. |
| 5 min | Students complete an individual reflection. | Check for individual understanding beyond team participation. |
| 5 min | Teacher closes by revisiting the essential question and naming examples of effective design and debugging. | Note concepts for future instruction. |
Assessment Plan
Formative Assessments
- Lesson 1 exit ticket on client, network, and server
- Teacher observations during the network simulation
- Algorithm and flow checks during planning
- Program checks during building
- Test logs and debugging conferences
- Peer feedback during testing
Summative Performance Assessment
Team product: A working or simulated menu-selection prototype, a labeled network diagram, and a brief demonstration.
Individual evidence: Each student completes a reflection explaining the network model, one programming or debugging decision, and one privacy or accessibility consideration.
| Criterion | 4 — Strong evidence | 3 — Meets target | 2 — Developing | 1 — Beginning |
|---|---|---|---|---|
| Network model | Clearly explains client, network, server, request, and response. | Correctly identifies the client, network, and server and describes a request or response. | Identifies some parts but confuses their roles. | Provides little or inaccurate explanation. |
| Program design | Program has clear input, organized steps, appropriate conditions, and useful outputs. | Program accepts a choice and gives an appropriate response for the planned options. | Some choices work, but steps or responses are incomplete. | Program does not yet show a clear input-to-output process. |
| Testing and debugging | Tests several inputs, records results, and explains a meaningful revision. | Tests at least three inputs and makes or explains a relevant improvement. | Testing is limited or the revision is unclear. | Provides little evidence of testing or debugging. |
| Safe and accessible design | Gives a specific, thoughtful privacy or accessibility choice. | Identifies one appropriate privacy or accessibility consideration. | Identifies a consideration but does not explain it clearly. | Does not yet identify a relevant consideration. |
| Communication and teamwork | Demonstrates the prototype clearly and explains team decisions with specific evidence. | Demonstrates the prototype and explains key decisions. | Demonstration or explanation is incomplete. | Needs substantial support to communicate the project. |
Differentiation and UDL Supports
- Multiple means of representation: Use a visual network diagram, physical role-play, teacher modeling, spoken directions, and written step cards. Preteach vocabulary with icons and examples.
- Multiple means of action and expression: Allow students to demonstrate learning through block-based code, a paper simulation, a labeled diagram, oral explanation, or a combination.
- Multiple means of engagement: Offer a choice of fictional menu items, roles, and presentation formats while keeping the same learning targets.
- Scaffolds: Provide a partially completed algorithm, sentence frames (“The client requests ___,” “The server returns ___”), a block-code starter, and a debugging checklist.
- Extensions: Invite students to add a second condition, improve error messages, compare two ways to represent a menu request, or explain how a real service might handle many requests.
- Language supports: Pair vocabulary with visuals; allow rehearsal with a partner; provide response frames and extra processing time.
- Collaboration supports: Assign rotating roles such as coder, tester, diagram designer, and presenter so every student contributes to the project.
Accommodations
Follow each student’s IEP, Section 504 plan, and documented classroom supports. Possible accommodations include:
- Provide accessible devices, keyboard alternatives, screen-reader-compatible materials, or enlarged text as needed.
- Offer directions in short, numbered steps with visual examples and checks for understanding.
- Allow additional time, breaks, or a quieter workspace.
- Provide a scribe, speech-to-text, or oral response option when writing is a barrier.
- Reduce the number of menu choices while preserving the learning target of input, conditional response, and testing.
- Pair students strategically and make sure each student has a meaningful role.
- Provide printed code blocks or a teacher-supported simulation when device access or motor demands make coding difficult.
Family and Community Connections
Invite students to explain the client–network–server model to someone at home using a simple drawing. Families can discuss how a digital menu might help people find information and why it should not request unnecessary personal details. If appropriate, invite a school technology staff member to describe, in age-appropriate terms, how school devices access shared resources. Do not ask families to share private food, health, or account information.
Teacher Reflection and Closure
At the
