CSC310 Lecture 21

Final Project
(20260824)

1. CSC 3100 Fundamentals of Software Engineering Lecture 21. Final Project Dr. Javier Gonzalez-Sanchez javiergs@calpoly.edu www.javiergs.phd ffi o ce: 14 -227
2. Key ideas
3. Key Ideas stories t sk UML PR (sever l) Metrics te m of 2 minimum P tterns: Purposeful, Not Forced a a a a a a a GUI, MQTT, Cont iner, MCP Actions (YML) JUnit (CI) CD (p ck ge)
4. The final project is where the semester’s ideas become one working system. 01 Requirements 02 Stories + criteria 04 MQTT Distributed behavior UML + OO Design 03 Responsible classes 05 JUnit + Actions Quality + CI Patterns + Events Deliberate structure 06 Docker + MCP Deploy + AI tools Open-ended problem • Common engineering expectations • Individual accountability
5. AI Assistant Human User Human User MCP Client Swing GUI Docker CLI / UI Local MCP Java Desktop Java Docker Java Server Application Application MQTT Broker Shared Events / State
6. Choose something worth building Robotics and sensor-driven applications are encouraged — but your topic is open. 01 03 Mobile robot 02 Robot arm Remote movement + position feedback Control commands + joint telemetry Possible: TURTLE4J / simulator Possible: RTDE4J / URSim IoT monitoring 04 Eye-gaze analysis Temperature, proximity, or alerts Live positions + visual summaries Simulated signals are acceptable WebGazer bridge + Java processing Simulation is fully acceptable. Real hardware is optional — not a grading advantage.
7. One system, three ways to interact All three interaction paths must work; reuse the same application logic. HUMAN HUMAN AI ASSISTANT Java Swing GUI Docker client Java MCP tools MQTT BROKER Commands • Measurements • State changes • Status events At least two independently running Java applications exchange meaningful MQTT messages. The MCP tool can call existing app logic or publish/query through MQTT — no duplicate domain logic required.
8. Non-negotiable contract
9. Make every element real and demonstrable. ✓ Java + Maven + dependencies A GOOD MVP ✓ 2+ apps that communicate via MQTT 1 Receive a command ✓ Swing GUI + Docker interface 2 Change the model ✓ AI assistant integration with a local Java MCP tool 3 Publish an event 4 Update the GUI 5 Query with AI/MCP ✓ ✓ JUnit 5 + GitHub Actions + Release UML + README + 3 justified patterns End-to-end behavior matters more than an impressive but disconnected feature list.
10. Use at least three design patterns Select from the course set — and explain why each pattern belongs in your design. Observer Builder Factory Decorator Composite Singleton Blackboard Strategy EXAMPLE · ROBOT CONTROL Observer: UI refresh Strategy: movement rules Factory: simulator selection Show participating classes in UML and justify each pattern in README. Show your engineering mind. Never overengineer just to satisfy a pattern count.
11. Your progress must be visible We assess both the working application AND the engineering process. 1 2 3 4 5 Story Assigned task Pull Request Review + CI Merged work Acceptance criteria Owner + status Code + tests Teammate + Actions Task / Story Done INSTRUCTOR ACCESS Repository + GitHub Project EVERY CHANGE Through reviewed PR — not direct main EVERY STUDENT ≥ 2 substantive PRs over time HONEST BOARD To Do · In Progress · Review · Blocked · Done Task ownership → PR diff → review → test evidence → merged outcome → individual evaluation.
12. Five stages. Instructor checkpoints. The idea must be approved before full implementation begins. PROPOSAL Pitch + instructor approval 02 REQUIREMENTS Stories, Tasks, owners, UML 03 FOUNDATION MQTT + Swing + Docker + MCP 04 INTEGRATION Patterns, tests, CI, metrics RELEASE Demo video + release + links 01 05 NOV 16–18 DEC 16
13. Grading
14. What the team delivers One repository. One Project board. One release. One demonstration. SOURCE + TESTS PROJECT HISTORY GitHub repo, Maven, JUnit, Actions, Docker, MCP Stories, sub-Tasks, assignees, honest status, PRs DESIGN + DOCS VIDEO + RELEASE Final UML PNG/JPEG, patterns, README, contribution list 7–10-minute working demo, all members, tagged artifacts DEMO CHECK Swing • Docker • MQTT • AI/MCP • JUnit/CI • Working release
15. You are evaluated for what YOU do A successful team result matters — but individual engineering is the main grade. 85% INDIVIDUAL 35 Design + implementation 15% TEAM 5 Working integration 20 Test cases, code quality + metrics 10 Integration + ownership 10 PRs 3 Release + deployment + docs 7 Architecture coherence 10 Individual demo + explanation Evidence: assigned Tasks, PR diffs, tests, peer review, and what each person can explain.
16. Proposal
17. The proposal: 5 slides, 5–7 minutes Every student speaks. Present your plan, not finished code. 01 Idea Problem and intended user 02 Architecture Apps, MQTT, Swing, Docker, MCP 03 Engineering 3 patterns, tests, dependencies 04 People + work Team roles, first Stories/Tasks 05 Feasibility MVP, risks, what you can cut Team size: 2–4. Scope must fit a realistic 3–4 weeks of work.
18. Questions
19. CSC 3100 Fundamentals of Software Engineering Javier Gonzalez-Sanchez, Ph.D. javiergs@calpoly.edu Fall 2026 Copyright Notice. These slides are provided exclusively for educational use in CSC 3100 within the California State University system. Redistribution or use for any other purpose is prohibited without prior written permission.