21 KiB
21 KiB
📱 Final Exam: Integrated Mobile Application Project
Flutter × Spring Boot × Object-Oriented Analysis and Design
Group Assignment (3 Members) — Industry-Grade Level
Overview
This final exam requires your group to design, develop, and deliver a fully integrated mobile application system consisting of:
- A Flutter mobile frontend that consumes a RESTful API
- A Spring Boot backend that exposes the API with proper layering, security, and persistence
- A rigorous OOAD process — designed before coding, then verified against the final implementation
The project is evaluated across three distinct dimensions with different grade weights. This is intentional: design thinking (OOAD) is the foundation, engineering quality (Flutter + Spring Boot) is the execution.
Group Formation & Role Distribution
Each group consists of exactly 3 members. Each member owns one primary pillar but all members must understand and contribute to all three.
| Role | Primary Pillar | Core Responsibilities |
|---|---|---|
| OOAD Lead | Object-Oriented Analysis & Design | Leads all design artifacts (use case, class, sequence, state diagrams), enforces design pattern compliance across both codebases, owns the design traceability matrix |
| Flutter Engineer | Mobile Frontend | Clean Architecture implementation, state management, UI/UX, performance benchmarking |
| Backend Engineer | Spring Boot API | REST API design, service/repository layers, database schema, security (JWT), API documentation, backend testing |
Important: Role ownership means accountability, not isolation. All members must commit code to both repositories. The OOAD Lead reviews both codebases for pattern compliance — this is a graded responsibility.
Project Topic
Your group is free to choose any application domain, provided it:
- Models a real-world problem with identifiable actors, use cases, and entities
- Requires meaningful backend logic (not just CRUD — include at least one business rule or workflow)
- Has a clear primary user and at least one secondary actor (admin, system, or external service)
Example domains (create your own — do not copy):
- Hospital appointment and queue management
- Campus asset borrowing and return tracking
- Community marketplace with seller verification flow
- Event ticketing with seat allocation logic
- Employee attendance with approval workflow
Pillar 1 — Object-Oriented Analysis & Design (OOAD)
OOAD is evaluated in two phases: design artifacts produced before coding, and a traceability audit conducted against the final code.
Phase 1A: Pre-Development Design Artifacts
All diagrams must be produced using PlantUML, draw.io, or StarUML and submitted as part of the Week 2–3 checkpoint. Diagrams drawn by hand are not accepted.
| Artifact | Diagram Type | Requirement |
|---|---|---|
| Requirements model | Use Case Diagram | All actors, use cases, include/extend relationships |
| Structural model | Class Diagram | All domain classes with attributes, methods, visibility, and relationships (association, aggregation, composition, inheritance) |
| Behavioral model | Sequence Diagrams | At least 3 key interactions (e.g., login, create resource, approval flow) showing object collaboration |
| State model | State Machine Diagram | At least 1 entity with meaningful state transitions (e.g., Order: PENDING → CONFIRMED → COMPLETED → CANCELLED) |
| Data model | ERD (Crow's Foot notation) | All entities, PKs/FKs, cardinality — must align with the class diagram |
| Architecture model | Component Diagram | Flutter app, Spring Boot layers, database, and external services as components with interfaces |
Phase 1B: Design Pattern Compliance
Your system must implement at least 4 GoF design patterns across the full stack, with at least 1 from each category:
| Category | Required Count | Examples |
|---|---|---|
| Creational | ≥ 1 | Factory Method, Builder, Singleton |
| Structural | ≥ 1 | Adapter, Facade, Decorator, Proxy |
| Behavioral | ≥ 2 | Strategy, Observer, Command, Template Method, Chain of Responsibility |
Each pattern must be documented with:
- Pattern name and category
- Which class/component implements it (with file path)
- UML class diagram showing the pattern in context
- Justification — why this pattern was chosen over alternatives
Phase 1C: Design Traceability Audit (Post-Development)
After development is complete, the OOAD Lead conducts a traceability audit comparing the pre-development design to the final code:
- For each class in the original class diagram: does it exist in code? If not, explain why.
- For each design pattern: show the exact code that implements it (file + line reference).
- For each sequence diagram: trace the method call chain in the actual code.
- Document all design deviations — cases where implementation diverged from design — with a written rationale for each deviation.
A perfect match between design and code is not required. Thoughtful, documented deviations are acceptable. Undocumented deviations are penalized.
Pillar 2 — Flutter Mobile Frontend
Technical Requirements
| Category | Requirement |
|---|---|
| Flutter Version | Flutter 3.x (Stable channel) |
| Architecture | Clean Architecture — strict 4-layer separation: domain / data / application / presentation |
| State Management | BLoC or Riverpod (consistent throughout; mixing is not allowed) |
| Navigation | Go Router with at least 6 distinct screens and route guards for authenticated routes |
| API Communication | Dio with interceptors for JWT token injection, refresh token handling, and error normalization |
| Local Persistence | Hive or SQLite for offline caching of at least one core data entity |
| Authentication | JWT-based login/register consuming the Spring Boot auth endpoint |
| UI/UX | Custom widget library (min. 5 reusable widgets), responsive layout, consistent design system |
| Error Handling | Typed failure classes using Either (dartz) or equivalent; no raw try/catch in UI layer |
Folder Structure (Enforced)
lib/
├── core/ # shared utilities, theme, constants, error types
├── features/
│ └── [feature]/
│ ├── domain/ # entities, repository interfaces, use cases
│ ├── data/ # repository implementations, DTOs, data sources
│ └── presentation/ # BLoC/Cubit, pages, widgets
└── main.dart
Any structure deviating from feature-first modular layout must be approved in writing before Week 4.
Advanced Features (Choose at least 2)
- Real-time updates via WebSocket or Server-Sent Events from Spring Boot
- Push notifications triggered by backend events (FCM)
- Offline-first with background sync to Spring Boot API
- Animated transitions using custom
PageRouteBuilderor Lottie - Internationalization (i18n) with at least 2 languages
- Biometric authentication (fingerprint/face ID) as second factor
Flutter Testing & Benchmarking
Functional Testing
| Type | Tool | Minimum |
|---|---|---|
| Unit Testing | flutter_test |
All use cases and repository implementations |
| Widget Testing | flutter_test |
At least 5 core UI components |
| Integration Testing | integration_test |
At least 3 end-to-end flows against the live Spring Boot API |
Performance Benchmarking
Run all benchmarks on a physical Android device in profile mode (flutter run --profile). Emulator results alone are not accepted.
| Metric | Tool | Pass Threshold |
|---|---|---|
| Memory — baseline | DevTools → Memory tab | Report heap at launch (MB) |
| Memory — leak check | DevTools → Memory tab | No steady growth over 10 repeated navigations |
| Frame rate / jank | DevTools → Performance tab | ≥ 90% frames < 16ms (60fps target) |
| CPU profile | DevTools → CPU Profiler | Flame graph for top 3 CPU-heavy operations |
| API latency (client-side) | Dio interceptor logs | All core endpoints < 1500ms |
| Cold start time | --trace-startup --profile |
timeToFirstFrame < 3000ms |
| APK size | flutter build apk --analyze-size |
Release APK < 50MB |
Each benchmark must be reported with: objective, tool, method, results table, threshold comparison, and DevTools screenshot.
Regression requirement: Run benchmarks at Week 5 (mid-sprint) and at Week 7 (final). Submit a delta table comparing both runs. Any metric that degrades > 20% must include a root cause analysis and remediation.
Pillar 3 — Spring Boot Backend
Technical Requirements
| Category | Requirement |
|---|---|
| Java Version | Java 17+ |
| Framework | Spring Boot 3.x |
| Architecture | Layered: Controller → Service → Repository (no logic in Controller, no DB calls in Service) |
| Database | PostgreSQL or MySQL with JPA/Hibernate; schema migrations via Flyway |
| Security | Spring Security with JWT (access token + refresh token); role-based access control (RBAC) |
| API Design | RESTful conventions; versioned endpoints (/api/v1/...); proper HTTP status codes |
| Validation | Bean Validation (@Valid) on all request DTOs; global exception handler via @ControllerAdvice |
| Documentation | Swagger/OpenAPI 3.0 via springdoc-openapi; all endpoints documented with schemas |
| Configuration | Environment-separated configs (application-dev.yml, application-prod.yml); no hardcoded secrets |
API Contract Requirements
- Minimum 10 distinct REST endpoints covering the full application domain
- All endpoints must return a consistent response envelope:
{
"success": true,
"data": {},
"message": "Operation successful",
"timestamp": "2025-01-01T00:00:00Z"
}
- Error responses must include:
success: false,errorCode,message, andtimestamp - API contract must be defined as an OpenAPI 3.0 YAML file committed to the repository before development begins (design-first)
Backend Testing & Benchmarking
Functional Testing
| Type | Tool | Minimum |
|---|---|---|
| Unit Testing | JUnit 5 + Mockito | All service classes; mock repository layer |
| Integration Testing | @SpringBootTest + MockMvc |
All controller endpoints; test DB via Testcontainers |
| Code Coverage | JaCoCo | ≥ 70% line coverage on service and controller packages |
Load Benchmarking
| Metric | Tool | Pass Threshold |
|---|---|---|
| API throughput | Apache JMeter or k6 | ≥ 100 req/s under 50 concurrent users |
| p95 latency | JMeter or k6 | < 500ms under load |
| Error rate under load | JMeter or k6 | < 1% at 50 concurrent users |
| DB query performance | Spring Actuator + slow query log | No query > 200ms for standard operations |
| JVM memory under load | Actuator /actuator/metrics |
No heap exhaustion during 5-min load test |
Load test scenario: simulate 50 concurrent users performing a realistic user journey (login → fetch list → create resource → logout) for 5 minutes. Export JMeter .jtl report or k6 summary as evidence.
Deliverables
1. 📁 GitHub Repositories (2 repos)
Flutter Repository ([GroupName]-[AppName]-mobile-final):
- Feature-first clean architecture folder structure
- GitHub Actions workflow (
.github/workflows/flutter.yml) — green at submission README.md: setup instructions, environment variables, APK download link- All 3 members must have commits; branching strategy enforced
Spring Boot Repository ([GroupName]-[AppName]-backend):
- Layered package structure (
controller,service,repository,domain,dto,config) - Flyway migration scripts in
resources/db/migration/ - OpenAPI YAML committed before Week 4
README.md: setup instructions, environment variables, how to run locally- JaCoCo HTML coverage report committed or published via CI
2. 📦 APK File
- Release build named
[GroupName]_[AppName]_FinalExam.apk - Must connect to a live, publicly deployed Spring Boot backend (not localhost)
- Acceptable deployment platforms: Railway, Render, Fly.io, or any public URL
3. 📄 Written Report
Format: PDF, minimum 25 pages (excluding cover and references). Language: English or Bahasa Indonesia.
| # | Section | Description |
|---|---|---|
| 1 | Cover Page | System name, group name, member names & student IDs, course name, date |
| 2 | Abstract | 200–250 words covering the system, tech stack, and key findings |
| 3 | Introduction | Problem background, objectives, target users, scope and limitations |
| 4 | OOAD — Pre-Development | All design artifacts (use case, class, sequence, state, ERD, component diagrams) |
| 5 | OOAD — Design Patterns | Documentation of all 4+ patterns with UML and code references |
| 6 | OOAD — Traceability Audit | Design-to-code mapping table; documented deviations with rationale |
| 7 | System Architecture | Flutter Clean Architecture, Spring Boot layers, API communication flow diagram |
| 8 | API Contract | OpenAPI summary, endpoint table, request/response examples |
| 9 | Flutter Implementation | Key features, state management flow, custom widgets, advanced features |
| 10 | Spring Boot Implementation | Service layer logic, security config, DB schema, Flyway migrations |
| 11 | Flutter Testing & Benchmarking | Test results, all 7 benchmark metrics with evidence and delta table |
| 12 | Backend Testing & Benchmarking | JUnit/integration test results, JMeter/k6 load test report |
| 13 | Team Contribution | Per-member task table with percentage, cross-verified with Git commit history |
| 14 | Conclusion | Achievements, design lessons learned, challenges, future improvements |
| 15 | References | IEEE format |
4. Presentation
- Duration: 15–20 minutes
- Structure:
- Team introduction + system overview (2 min)
- OOAD design walkthrough — diagrams and pattern explanation (4–5 min)
- Flutter app live demo — all major flows (5–6 min)
- Spring Boot API demo — Swagger UI + one live API call (3 min)
- Benchmark results summary (2 min)
- All 3 members must present a section
- Upload to YouTube (unlisted) or Google Drive
Live Session: Each member will be questioned individually on the section they presented and on OOAD concepts. Individual scores may differ from the group score.
Timeline
| Phase | Activity | Deadline |
|---|---|---|
| Week 1 | Group registration + topic proposal + actor/use case list | Day 7 |
| Week 2–3 | All OOAD Phase 1A artifacts submitted + OpenAPI YAML drafted | Day 21 |
| Week 4 | Architecture approved; development sprint begins | Day 28 |
| Week 5 | Mid-sprint benchmark run (Flutter + Backend) submitted | Day 35 |
| Week 6–7 | Feature freeze; Flutter ↔ Spring Boot integration testing | Day 49 |
| Week 7 | Final benchmark run; delta table completed | Day 49 |
| Week 8 | OOAD traceability audit completed; report writing + video | Day 56 |
| Final | All deliverables submitted | Day 60, 23:59 |
| Final+1 | Live presentation & individual Q&A | Scheduled by lecturer |
Grading Rubric
Each pillar is graded independently out of 100 points. Students receive three separate scores — one per pillar. There is no combined final grade: each score stands on its own and is recorded separately.
🥇 Pillar 1 — OOAD Score (/ 100)
| Component | Points | Criteria |
|---|---|---|
| Pre-development design artifacts | 35 | Completeness of all 6 required diagrams, correctness of notation, diagram tool used (no hand-drawn), submitted before coding begins |
| Design pattern implementation | 25 | Correct application of ≥ 4 GoF patterns (min 1 per category), UML documented per pattern, each traceable to code with file path |
| Traceability audit | 25 | Coverage of class-to-code mapping, quality and honesty of deviation documentation, sequence diagram trace accuracy |
| Cross-pillar design consistency | 15 | Alignment between class diagram, ERD, Flutter domain layer entities, and Spring Boot domain/entity classes |
OOAD Penalty:
| Violation | Deduction |
|---|---|
| OOAD artifacts submitted after Week 3 (after coding begins) | −20 points |
| Diagram produced with unpermitted tool (e.g., hand-drawn, screenshot of AI output) | −15 points |
| Design pattern claimed but not traceable in code | −8 points per pattern |
| Traceability audit missing for > 30% of class diagram classes | −10 points |
🥈 Pillar 2 — Flutter Mobile Score (/ 100)
| Component | Points | Criteria |
|---|---|---|
| Clean Architecture compliance | 25 | Strict 4-layer separation enforced, no cross-layer violations, feature-first folder structure correct, dependency direction correct |
| Features & UX quality | 20 | All required screens functional, JWT auth flow works against live API, custom widget library present, error states handled |
| Testing — unit & widget | 15 | All use cases and repositories covered, at least 5 widget tests, test quality (meaningful assertions, not just coverage padding) |
| Testing — integration | 10 | At least 3 end-to-end flows tested against live Spring Boot API, not mocked |
| Performance benchmarking | 20 | All 7 metrics reported on physical device in profile mode, DevTools screenshots provided, delta table (mid vs final), root cause for any regression > 20% |
| Report clarity | 10 | Report is complete and have clear explanation |
Flutter Penalty:
| Violation | Deduction |
|---|---|
| Responsive Design fail | −10 points |
| Benchmarks run on emulator only (no physical device) | −10 points |
| Missing delta table (mid-sprint vs final benchmark) | −8 points |
| State management inconsistency (mixing BLoC and Riverpod) | −10 points |
Raw try/catch found in presentation layer |
−5 points per occurrence (max −15) |
| APK connects to localhost instead of deployed backend | −15 points |
🥉 Pillar 3 — Spring Boot Score (/ 100)
| Component | Points | Criteria |
|---|---|---|
| API design & OpenAPI contract | 25 | ≥ 10 endpoints, consistent response envelope, versioned routes, OpenAPI 3.0 YAML committed before Week 4, Swagger UI accessible |
| Layered architecture & security | 25 | Strict Controller → Service → Repository separation, JWT with access + refresh token, RBAC with at least 2 roles, no hardcoded secrets |
| Testing — unit & integration | 25 | JUnit 5 + Mockito for all service classes, MockMvc + Testcontainers for all controllers, JaCoCo ≥ 70% on service and controller packages |
| Load benchmarking | 25 | All 5 metrics reported (throughput, p95 latency, error rate, DB query time, JVM heap), JMeter .jtl or k6 summary exported, analysis against pass thresholds |
Spring Boot Penalty:
| Violation | Deduction |
|---|---|
| Hardcoded secrets (API keys, DB passwords) in any file | −15 points |
| JaCoCo coverage below 70% | −10 points |
| No Flyway migrations (schema managed manually) | −8 points |
| OpenAPI YAML committed after Week 4 | −10 points |
| Load test run with < 50 concurrent users | −10 points |
| Business logic found directly in Controller class | −8 points per occurrence (max −16) |
Universal Penalty (Applied to All Three Pillar Scores)
| Violation | Deduction |
|---|---|
| Late submission (per day, applied to all pillars) | −5 points per pillar |
| Missing deliverable | −15 points from the relevant pillar |
| Plagiarized code (any source) | 0 on all three pillars |
| Member with < 10% commits and no other contribution evidence | That member's individual pillar scores reduced by 20 points each |
Academic Integrity
- All code must be original. Open-source libraries are permitted with proper attribution in both READMEs and the report.
- Use of AI coding assistants is permitted but must be disclosed in a dedicated "AI Tool Usage" section in the report, listing which tools were used, for which tasks, and how outputs were reviewed and understood.
- Design artifacts must be produced by the group. AI-generated diagrams submitted without annotation will be identified during the live Q&A.
- Plagiarism between groups or from public repositories results in zero marks for all involved groups.
Submission Checklist
- Flutter GitHub repository (Actions pipeline green, branch protection active, 3+ merged PRs)
- Spring Boot GitHub repository (JaCoCo report committed, OpenAPI YAML present, Flyway migrations included)
- APK file connecting to live deployed backend (
[GroupName]_FinalExam.apk) - Written report PDF (≥ 25 pages, all 16 sections complete, benchmark delta table included)
- Demo video link (YouTube unlisted or Google Drive, all 3 members presenting)
- OOAD traceability matrix (Section 6 of report)
- Mid-sprint benchmark results (Sections 11 & 12 of report)
- JMeter/k6 load test export (appendix or Drive link)
Contact & Questions
All questions must be submitted through the official course channel. Questions submitted at least 48 hours before any deadline are guaranteed a response. Design artifact reviews (Week 2–3) require a scheduled appointment — contact the lecturer by Week 1 to book a slot.
Build systems you can defend, designs you can explain, and code that reflects your thinking. 🚀