São poucos dias de aula (25 e 26) mais trabalho fora. Planeje pequeno: é melhor um núcleo simples que roda de ponta a ponta do que um projeto ambicioso pela metade na entrega.
Faça o núcleo rodar de ponta a ponta antes de sofisticar. Recurso extra é bônus.
Boa parte do desenvolvimento acontece fora da aula. Combine com sua dupla um ritmo de trabalho e commits frequentes no GitHub.
| Aula | Data | O quê |
|---|---|---|
| 25 | 09/07 | Briefing, dupla, tema e início da modelagem |
| 26 | 10/07 | Desenvolvimento com acompanhamento |
| 27 | 13/07 | Finalização, testes e preparar a apresentação |
| 28 | 14/07 | 2ª VA — prova prática individual (não é o projeto) |
| 29 | 16/07 | Apresentação ao vivo das duplas |
Prazo do GitHub: o repositório publicado até 24h antes da apresentação — ou seja, no ar até ~15/07 (dia sem aula, organize-se com sua dupla fora do horário).
O diagrama de classes é o mapa do código. Decidir as classes no papel custa minutos; descobrir que a modelagem estava errada no meio do código custa horas de retrabalho.
Minutos no papel poupam horas no código.
Uma classe do seu modelo vira uma tabela: cada objeto é uma linha, cada atributo é uma coluna. Copie o molde do RepositorioProduto da aula 24 e troque Produto pela sua classe.
import sqlite3
from pathlib import Path
BANCO = Path(__file__).parent / "app.db" # o .db ao lado do script (aula 22)
# Troque "Produto" e as colunas pela SUA classe
class RepositorioProduto:
def __init__(self, caminho=BANCO):
self.caminho = caminho
self.criar_tabela()
def criar_tabela(self):
with sqlite3.connect(self.caminho) as conexao: # o with commita sozinho
conexao.execute("""
CREATE TABLE IF NOT EXISTS produtos (
id INTEGER PRIMARY KEY AUTOINCREMENT,
nome TEXT NOT NULL,
preco REAL NOT NULL
)
""")
def salvar(self, produto): # CREATE
with sqlite3.connect(self.caminho) as conexao:
cursor = conexao.execute(
"INSERT INTO produtos (nome, preco) VALUES (?, ?)",
produto.to_params()) # aula 24: objeto vira tupla
produto.id = cursor.lastrowid # o banco gerou o id
return produto
def listar(self): # READ (todos)
with sqlite3.connect(self.caminho) as conexao:
cursor = conexao.execute(
"SELECT id, nome, preco FROM produtos ORDER BY id")
return [Produto.from_row(linha) for linha in cursor.fetchall()]
def atualizar(self, produto): # UPDATE
with sqlite3.connect(self.caminho) as conexao:
conexao.execute(
"UPDATE produtos SET nome = ?, preco = ? WHERE id = ?",
(produto.nome, produto.preco, produto.id))
def remover(self, id): # DELETE
with sqlite3.connect(self.caminho) as conexao:
conexao.execute("DELETE FROM produtos WHERE id = ?", (id,))A GUI fala com o repositório, não com o SQL: a janela chama repo.salvar(...), repo.listar(...), e nunca escreve INSERT/SELECT direto. Assim a interface fica limpa e o banco fica escondido atrás de métodos com nome de negócio.
A largada do projeto que fecha o curso. Hoje é briefing, escolha de tema e começar a modelar.
A ideia central
o raciocínio orientado a objetos — o critério-mor.
dados que sobrevivem ao fechar o programa.
interface gráfica funcional, com eventos.
O que vamos avaliar em você
Traduzir um problema real em classes e representá-lo num diagrama de classes (UML).
Aplicar herança, polimorfismo, encapsulamento e abstração de forma justificada — não decorativa.
Guardar os dados num banco para que sobrevivam ao fechar o programa.
Construir uma janela funcional, tratando os eventos (botões, campos, listas).
Explicar as decisões técnicas — por que cada classe, cada herança, cada escolha.
Escopo — leia com atenção
base + subclasses com polimorfismo real.
SQLite persistindo: cadastrar, listar, editar, apagar.
Tkinter tratando eventos, usável.
As regras do jogo
Filtro rápido antes de decidir
Tema 1 · Organize tarefas com prazo e status
Tarefa como base, com subclasses TarefaSimples e TarefaComPrazo — herança e polimorfismo (cada tipo mostra/verifica o prazo do seu jeito). Tema 2 · Registre entradas e saídas e veja para onde vai o dinheiro
Lancamento com subclasses Receita e Despesa — polimorfismo no impacto sobre o saldo (uma soma, a outra subtrai) e encapsulamento protegendo os valores. Tema 3 · Baralhos e cartões para fixar conteúdo
Baralho e Cartao em composição (um baralho tem vários cartões), com métodos de embaralhar e pontuar. Tema 4 · Centralize contatos com busca rápida
Contato, com possível hierarquia ContatoPessoal/ContatoProfissional, e encapsulamento com validação nos setters (e-mail e telefone só entram se forem válidos). Tema 5 · Saiba o que tem, sem perder venda
Produto e classe Estoque que gerencia a coleção (composição), com métodos que aplicam regra de negócio — não deixar a quantidade ficar negativa. Tema 6 · Catalogue o que você já consumiu
ItemDeMidia com subclasses Livro, Filme e Jogo, cada uma com atributos próprios; polimorfismo na exibição da ficha (__str__). Tema 7 · Registre hábitos e acompanhe a sequência (streak)
Habito com subclasses HabitoSimples (sim/não) e HabitoComMeta (ex.: beber 2L) — polimorfismo em como cada tipo verifica o cumprimento. Tema 8 · Marque horários sem se perder no papel
Cliente, Servico e Agendamento em composição; encapsulamento das regras (não agendar horário já ocupado) e um método de listagem por dia. O que a dupla precisa entregar
Qual problema o app resolve, por que vocês escolheram e as funcionalidades planejadas. Um documento de 1–2 páginas, entregue em PDF.
Classes, atributos, métodos e as relações entre elas. Entregue em PDF.
O projeto .py rodando: Tkinter + SQLite + POO trabalhando juntos.
Demo ao vivo do app + explicação das decisões técnicas. Cerca de 10 minutos, com os dois integrantes falando.
💾3 artefatos (documento, diagrama, código) + a apresentação. Os dois integrantes participam de tudo.
Onde e quando entregar
descrição + motivação (1–2 páginas).
classes e relações, imagem ou PDF.
Tkinter + SQLite + POO rodando.
Template de entrega
Nome do projeto + os 2 integrantes; o problema; a motivação; as funcionalidades planejadas; e quais conceitos de POO vão usar e onde.
Todas as classes com atributos e métodos; a visibilidade (público/privado/protegido); as relações (herança/composição/associação). O diagrama tem que bater com o código — se mudar o código, atualize o diagrama.
Uso real de POO; SQLite com CRUD funcionando; Tkinter com eventos tratados; comentários nas partes principais.
Demo ao vivo; mostrar os pontos-chave e os aprendizados; preparados para perguntas; os dois falam.
Rubrica
| item | detalhe |
|---|---|
| Documentação | Descrição e motivação claras; problema real bem definido. |
| Modelagem UML | Diagrama coerente com o código; relações corretas (herança × composição × associação). |
| Aplicação de POO | Uso real de classes, herança, polimorfismo, encapsulamento e abstração — não só 'código que funciona'. |
| Banco de dados | Persistência com SQLite funcionando; os dados sobrevivem ao fechar o programa. |
| Interface Tkinter | Funcional, organizada e usável; eventos tratados. |
| Apresentação | Demonstra o app, mostra os pontos-chave e aprendizados, e responde às perguntas. |
O critério que mais pesa
if tipo == ... onde cabia polimorfismo. O que separa uma da outra
É o mesmo conceito das duas — o que muda é se você usou porque precisava ou só para "parecer POO".
Antes da primeira linha de código
Mão na massa — modelagem
Eles viram candidatos a classe: Tarefa, Usuário, Categoria, Produto…
O que ela guarda (nome, preco, _placa) e o que ela faz (concluir(), valor()).
Público (+), privado (-), protegido (#). O que passa por property/setter é privado.
Herança (seta com triângulo, "é um") e composição/associação (linha, "tem um").
Uma caixa por classe (nome / atributos / métodos) e conecte pelas relações. Numa ferramenta de UML ou no papel — como a dupla preferir. Na entrega, exporte ou fotografe em PDF.
💾Comece com 2–3 classes essenciais. O diagrama precisa acabar batendo com o código.
A decisão que define a seta
A pergunta que decide a seta: "X é um Y, ou X tem Y?"
A camada de dados do projeto
RepositorioProduto da aula 24 — salvar, listar, buscar, atualizar, remover — e troque Produto pela sua classe. o molde do CRUD encapsulado.
de onde veio a ideia de gravar dados.
Linha do tempo
modelar e desenvolver.
testes e apresentação.
prova prática individual.
demo ao vivo.
Agora, nos próximos 40 minutos
Depois do diagrama
Crie a base + as subclasses, com __init__ e __str__. Rode: crie um objeto e dê print nele.
property/setter no que tem regra. Teste de propósito com um valor inválido — o erro tem que aparecer.
Copie o molde da aula 24. Salve e liste — confirme que os dados persistem ao reabrir o programa.
Um campo, um botão, uma lista — chamando o repositório (nunca o SQL direto).
try/except; uma exceção própria quando fizer sentido (pátio lotado, item não encontrado).
💾Rode a cada passo, método por método. Faça o núcleo rodar antes de sofisticar.
Amanhã é studio: você desenvolve e eu tiro dúvidas — POO, arquivos, SQLite, revisão de código ao vivo e checkpoint diagrama × código. Venha com o modelo rascunhado de hoje.