English lesson plan for 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.: dragon ball lunch
Your lesson plan at a glance
A clear path to bring “dragon ball lunch” into your classroom and adapt it to your students’ needs.
View teaching context, adaptations and materials
This ready-to-use lesson plan for 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. students is built around the topic “dragon ball lunch”. It is organized so you can read it quickly, adapt it to your group and download it for the classroom.
The sequence follows project-based learning with guided practice. 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. Focused practice of the target language through guided, student-centered activities.
Assessment is formative: observe participation and oral production, review written work and use quick checks for understanding. The Word version is editable so you can adjust activities, timing and materials.
Lesson plan overview
Start with the key elements of the plan. The full sequence follows below.
General details and purpose
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. · Lesson plan. Subject: Computer Science.
Purpose: 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.
Methodology: Project-based learning with guided practice
Focus and structure
Focused practice of the target language through guided, student-centered activities.
Learning outcomes
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.
Articulating axes and standards
Standards are paraphrased for planning. Confirm exact wording and grade-band expectations in the version adopted by your state or district.
Final product
A short group presentation or written product that shows the new language in use.
Formative assessment
View criteria and evidence
Observe participation and oral production, review written work and use quick checks for understanding.
Materials
View full list
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.
Adaptations for your class
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.
Full lesson plan
The complete sequence with activities, timing, resources and evidence of learning.
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
Before you download
Overview, purpose and focus
- Computer Science
- By the end of the project, students will be able to:. 1. Describe how a client device, network, and server work together to sen?
Activities, product and assessment
- Student devices with a block-based programming tool, such as Scratch, or paper, cards, and markers for an unplugged version. Pr?
- A short group presentation or written product that shows the new language in use.
Your material is ready to download
Choose Word or PDF from one place.
Frequently asked questions about this lesson plan
Which grade is this lesson plan designed for?
It is designed for 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.. You can adjust the language level and timing to fit your group.
What methodology does the plan use?
It uses project-based learning with guided practice, with clear activities, evidence of learning and formative checks.
Can I edit and print the plan?
Yes. The Word version is editable and the PDF is ready to print. Adapt activities, materials and timing to your students.
Does it include materials and assessment?
Yes. The plan lists suggested materials, formative checks and a final product so you can plan the whole lesson.
