NOTAS DO PROFESSOR 📖 Apresentação inicial Esta unidade é transversal aos cursos de Técnico de Desenvolvimento de Software, Técnico de Sistemas de Computação e Redes e Técnico de Multimédia. É a primeira UC propriamente técnica de programação que muitos alunos enfrentam. 🗣️ Pontos a desenvolver oralmente • Enquadrar a UC no plano global do curso (componente tecnológica, transversal a UCs futuras de programação) • Sublinhar que não se trata ainda de uma linguagem específica, mas sim do pensar computacionalmente que vai sustentar tudo o resto • Explicar que o referencial é da ANQEP/SNQ (2025) e que o conteúdo segue rigorosamente o publicado em catalogo.snq.gov.pt ❓ Perguntas para a turma • "Alguém aqui já programou alguma coisa? O quê? Em que linguagem?" • "Quando ouvem a palavra 'algoritmo', em que pensam?" • "Conseguem dar um exemplo de algoritmo que usem todos os dias?" 💡 Sugestões pedagógicas Aproveitar o primeiro contacto para fazer um diagnóstico informal: alguns alunos terão noções básicas (Scratch, Python), outros nenhuma. Adaptar o ritmo das primeiras aulas em função. ⏱️ Tempo estimado: 5-7 minutos

NOTAS DO PROFESSOR 📖 Conceito-chave: Resultados de Aprendizagem Os resultados de aprendizagem são afirmações verificáveis sobre o que se espera que o aluno saiba, compreenda ou seja capaz de fazer no final do processo formativo. São a base da avaliação. No contexto SNQ/ANQEP, são designados por "realizações" e cada um corresponde a critérios de desempenho específicos. 🗣️ Pontos a desenvolver oralmente • Cada um destes 5 resultados será objeto de avaliação separada — explicar o sistema de descritores 0-20 • As 25 horas da UC distribuem-se por uma combinação destas realizações (não é proporcional, mas todas têm de ser cumpridas) • Os critérios são transversais — atravessam todas as realizações ❓ Perguntas para a turma • "Qual destes 5 vos parece mais difícil à partida? Porquê?" • "Já alguma vez 'definiram um problema' formalmente, em qualquer disciplina?" • "O que pode ser depurar um algoritmo?" 💡 Sugestões pedagógicas Imprimir os descritores oficiais (gerados em conteudos/avaliacao/UC00245-criterios-descritores.html) e distribuir na primeira aula para que cada aluno saiba como será avaliado. ⏱️ Tempo estimado: 5 minutos

NOTAS DO PROFESSOR 📖 Distribuição temporal 14 aulas de 90 minutos ≈ 21 horas lectivas + 4 horas para avaliação formativa e revisões = 25 horas. Adaptar conforme o calendário da escola. 🗣️ Pontos a desenvolver oralmente • A avaliação segue o modelo oficial DGE para cursos profissionais • Apresentar os instrumentos previstos: 2 fichas de avaliação escrita, 1 projeto prático, observação contínua, autoavaliação • Reforçar a parte das atitudes e valores: 20% da nota final é assiduidade, pontualidade, empenho e colaboração ❓ Perguntas para a turma • "Quem está habituado a ter avaliação contínua versus testes? Sentem que avalia melhor o que sabem?" • "Que tipo de instrumento de avaliação acham mais justo para programação?" 💡 Sugestões pedagógicas Mostrar fisicamente (ou projetar) a grelha de instrumento gerada para esta UC (conteudos/grelhas/UC00245-instrumento.html). A transparência sobre o sistema de avaliação reduz ansiedade. ⏱️ Tempo estimado: 5 minutos

NOTAS DO PROFESSOR 📖 Enquadramento do bloco O pensamento computacional (PC) é hoje reconhecido como competência básica do século XXI, ao nível da leitura e da escrita. Foi popularizado por Jeannette Wing em 2006 ("Computational Thinking", Communications of the ACM). Apesar do nome, não requer computador — é uma forma de raciocinar sobre problemas. 🗣️ Pontos a desenvolver oralmente • Diferenciar "saber usar o computador" (literacia digital) de "pensar computacionalmente" • Mencionar que mesmo profissões não-tecnológicas usam PC (chefs de cozinha, engenheiros, médicos) ❓ Perguntas para a turma • "O que vos vem à cabeça quando dizem 'pensar como o computador'?" • "Acham que alguém pode ser bom em programação sem ser bom a matemática?" ⏱️ Tempo estimado: 2 minutos (slide de transição)

NOTAS DO PROFESSOR 📖 Conceito-chave: Pensamento Computacional A definição de Wing é hoje canónica. Importante notar que ela usa "computador humano ou máquina" — isto é, o algoritmo é executável por qualquer agente que siga instruções precisas. 🗣️ Pontos a desenvolver oralmente • Insistir que o pensamento computacional é independente da linguagem de programação • Dar exemplo concreto: um manual de montagem IKEA é um algoritmo (passos sequenciais, condicionais "se a peça A não encaixar, vire-a 180º", repetições "aperte os 4 parafusos") ❓ Perguntas para a turma • "Concordam que o manual da IKEA é um algoritmo? Porquê?" • "Que profissões usam mais pensamento computacional sem dar por isso?" • "Já alguma vez seguiram uma receita e ela falhou por estar mal escrita? Foi por que motivo?" 💡 Sugestões pedagógicas Trazer uma receita ou manual de montagem mal redigido e analisar com a turma — é uma forma directa e divertida de mostrar a importância da precisão algorítmica. ⏱️ Tempo estimado: 6-8 minutos

NOTAS DO PROFESSOR 📖 Conceito-chave: 4 pilares (Computer Science Teachers Association) Esta divisão em 4 pilares é a mais consensual no ensino. Alguns autores acrescentam "Generalização" como 5º pilar (aplicar a solução a outros problemas semelhantes). 🗣️ Pontos a desenvolver oralmente para cada pilar • **Decomposição:** "fazer o jantar" → "comprar ingredientes" + "preparar" + "cozinhar" + "servir" • **Padrões:** se já fizemos um algoritmo para ordenar números, podemos adaptá-lo para ordenar palavras (alfabeticamente) • **Abstração:** um mapa do metro ignora distâncias reais — abstrai-se ao que importa para o utilizador (paragens e ligações) • **Algoritmo:** consequência natural dos 3 anteriores — a "receita" final ❓ Perguntas para a turma • "Decomponham 'arrumar o quarto' em pelo menos 5 sub-tarefas" • "Que padrões reconhecem entre fazer um trabalho de Português e um trabalho de História?" • "Pensem num mapa do Metro de Lisboa: o que está abstraído e o que ficou?" • "Se tivessem de explicar a um marciano como atravessar a rua, que passos dariam?" 💡 Sugestões pedagógicas Exercício prático rápido (5 min): pedir à turma para decompor "fazer um sandes de fiambre" em pelo menos 8 passos. Comparar respostas — alguns serão demasiado vagos ("preparar tudo"), outros demasiado detalhados ("levantar braço direito, agarrar faca"). Discutir o equilíbrio. ⏱️ Tempo estimado: 10-12 minutos

NOTAS DO PROFESSOR 📖 Caso prático integrador Este exemplo cobre os 4 pilares num cenário familiar a todos os alunos. Note-se que o algoritmo já antecipa a notação de pseudocódigo (INICIO/FIM, SE/SENÃO) que será formalizada mais adiante. 🗣️ Pontos a desenvolver oralmente • Sublinhar a presença implícita de uma condição (SE encontrar) e de uma alternativa (SENÃO) — primeira pista da estrutura "alternativa" que vamos estudar • Mostrar como diferentes pessoas podem produzir algoritmos diferentes para o mesmo problema, mas todos válidos se respeitarem as características de finitude, definição e eficácia ❓ Perguntas para a turma • "E se o livro estiver requisitado? Que passo acrescentariam?" • "Como mudaria o algoritmo se a biblioteca não tivesse sistema de classificação?" • "Conseguem identificar onde está uma 'repetição' implícita neste algoritmo?" (procurar livro a livro na estante) 💡 Sugestões pedagógicas Variar o exemplo conforme o perfil da turma: se forem do Multimédia, usar "encontrar uma fotografia específica no telemóvel"; se forem do Sistemas/Redes, usar "encontrar um ficheiro num servidor". ⏱️ Tempo estimado: 8-10 minutos

NOTAS DO PROFESSOR 📖 Enquadramento Após o pensamento computacional como contexto, entramos no conceito central da UC. O algoritmo é a unidade básica de raciocínio computacional. Esta secção é puramente conceptual — ainda não escrevemos código. ⏱️ Tempo estimado: 1-2 minutos (transição)

NOTAS DO PROFESSOR 📖 Conceito-chave: Algoritmo (Donald Knuth, "The Art of Computer Programming", 1968) A definição de Knuth é a referência. As cinco características são o teste de validade de qualquer algoritmo. Se algum falha, não temos um algoritmo (temos uma "heurística", um "procedimento" ou uma "ideia"). 🗣️ Pontos a desenvolver oralmente • **Finitude:** "encontrar todos os números primos" não é algoritmo (são infinitos); "encontrar todos os primos menores que N" é • **Definido:** "misture bem" não é definido — "agite durante 30 segundos" é • **Eficaz:** dividir por zero não é eficaz; "calcular a raiz quadrada de -1 no domínio real" não é eficaz • **Determinístico:** rand() não é determinístico — daí termos algoritmos não-determinísticos como uma categoria à parte • **I/O:** alguns algoritmos não recebem entrada (ex: gerar primeiros 10 números pares), mas todos têm de produzir alguma saída útil ❓ Perguntas para a turma • "Dêem-me um exemplo de instrução AMBÍGUA do dia-a-dia" • "O algoritmo 'enquanto não ganhar a lotaria, joga' cumpre a finitude? Porquê?" • "Conseguem dar exemplo de duas instruções que produzem resultados diferentes na mesma entrada?" 💡 Sugestões pedagógicas Exercício de classificação rápida (cartas A/B/C/D/E correspondentes às 5 características): ler instruções e a turma vota qual falha. Exemplos: "fazer feliz alguém" (Definido), "calcular x/0" (Eficaz), "atirar dado e devolver o valor" (Determinístico). ⏱️ Tempo estimado: 10 minutos

NOTAS DO PROFESSOR 📖 Conceito-chave: Algoritmo vs Programa Esta é uma das distinções mais importantes para qualquer programador. Um algoritmo é um plano; um programa é a sua execução numa linguagem particular. O mesmo algoritmo de ordenação (quicksort) pode ser implementado em Python, C, Java, JavaScript — produz programas diferentes mas o algoritmo é o mesmo. 🗣️ Pontos a desenvolver oralmente • Comparar com a construção civil: o algoritmo é a planta arquitectónica, o programa é a casa construída • Os algoritmos de Euclides (300 a.C.) ainda são usados hoje em programas modernos (RSA, criptografia). O algoritmo persiste, os programas vão mudando • Por isso o módulo se chama "Desenvolver algoritmos" e não "Desenvolver programas" — é a fundação que vai durar ❓ Perguntas para a turma • "Se mudar de Python para JavaScript, o algoritmo muda? E o programa?" • "Conseguem nomear um algoritmo que use uma app vossa?" (ex: TikTok usa algoritmo de recomendação) • "Quem é responsável quando um algoritmo discrimina pessoas — quem fez o algoritmo ou quem programou?" 💡 Sugestões pedagógicas Mostrar lado-a-lado o mesmo algoritmo (somar dois números) em pseudocódigo, Python, C e JavaScript. Demonstrar visualmente que a lógica é a mesma, só muda a "embalagem". ⏱️ Tempo estimado: 8-10 minutos

NOTAS DO PROFESSOR 📖 Conceito-chave: Estado da computação O estado é o conjunto de valores que descrevem completamente a situação do programa num dado instante. A execução de um algoritmo é uma sequência de transições entre estados, provocadas pelas acções (instruções). 🗣️ Pontos a desenvolver oralmente • A visão de "máquina de estados" é fundamental para entender depuração — quando um bug ocorre, descobrimos por que estado o programa passou (e não devia ter passado) • Em programação, o estado é principalmente o valor das variáveis na memória + posição no ficheiro + fluxo de execução • Esta visão prepara o terreno para a trace table (tabela de execução) que veremos mais à frente ❓ Perguntas para a turma • "Imaginem um jogo de xadrez. Qual é o estado do jogo num dado momento?" • "Quando carregam 'reset' num jogo, o que acontece ao estado?" • "O estado inicial e o estado final do algoritmo são iguais? Quando podem ser?" 💡 Sugestões pedagógicas Usar o exemplo da máquina de café: estado inicial (sem água, sem café), acção (pôr água), novo estado (com água, sem café), acção (pôr café), estado final (pronto a fazer). Cada acção transforma um estado noutro. ⏱️ Tempo estimado: 8 minutos

NOTAS DO PROFESSOR 📖 Reforço prático Estes exemplos demonstram que algoritmos são omnipresentes. Importante para que os alunos percebam que NÃO estão a aprender uma coisa nova, estão a formalizar algo que já fazem todos os dias. 🗣️ Pontos a desenvolver oralmente • Cada um destes pode ser escrito como pseudocódigo formal — vamos fazê-lo na próxima aula • Notar a presença de condições implícitas: "olhar para a esquerda — SE houver carro, esperar" • Os algoritmos digitais (levantar dinheiro, login) são versões formalizadas e auditadas dos exemplos físicos ❓ Perguntas para a turma • "Escolham um destes e descrevam todos os passos com pormenor — incluindo casos de erro (cartão danificado, água a ferver excessivamente, etc.)" • "Qual destes 4 acham mais difícil de transformar em algoritmo formal? Porquê?" • "Sabem o que acontece tecnicamente quando inserem o cartão na multibanco? Quais são as condições?" 💡 Sugestões pedagógicas Pedir aos alunos para escolherem uma actividade do seu dia-a-dia e escreverem como pseudocódigo informal (linguagem natural numerada). Será o input para a próxima aula sobre representação formal. ⏱️ Tempo estimado: 8 minutos

NOTAS DO PROFESSOR 📖 Transição Saímos do "o que é" e entramos no "como construir". Os dados são a matéria-prima dos algoritmos. ⏱️ Tempo estimado: 1 minuto

NOTAS DO PROFESSOR 📖 Conceito-chave: Tipos de dados A tipagem (typing) é um dos conceitos mais importantes de programação. Um tipo define que valores uma variável pode tomar e que operações são válidas. Tentar somar "Olá" + 5 numa linguagem com tipos estritos dá erro. 🗣️ Pontos a desenvolver oralmente • Distinguir tipos primitivos (atómicos) de tipos compostos (que veremos em UCs futuras — listas, dicionários, objectos) • Real vs Inteiro: a divisão 10/3 dá resultado diferente conforme o tipo. Em pseudocódigo, vamos distinguir DIV (divisão inteira) e / (divisão real) • Booleano (lógico) é a base de toda a tomada de decisão computacional ❓ Perguntas para a turma • "Que tipo de dado representam: idade, nome, salário, casado/solteiro, código postal?" • "Porque é que o código postal '0742' deve ser cadeia e não inteiro?" • "Quantos valores lógicos existem? E se acrescentássemos 'Talvez', quantos seriam?" 💡 Sugestões pedagógicas Exercício rápido na grelha: dar 10 valores do mundo real e a turma classifica o tipo mais adequado. Ex: NIF (cadeia, não inteiro — leading zeros), preço (real), número de filhos (inteiro), avatar (cadeia/URL). ⏱️ Tempo estimado: 10 minutos

NOTAS DO PROFESSOR 📖 Conceito-chave: Variável e atribuição Uma variável é um espaço nomeado em memória onde se guarda um valor. A atribuição (representada por ← ou = consoante a notação) NÃO é igualdade matemática — é uma operação que muda o conteúdo da variável. 🗣️ Pontos a desenvolver oralmente • A linha "total ← total + 10" confunde alunos com formação matemática forte — em matemática isto seria impossível (x = x + 10 ⟹ 0 = 10) • Explicar a leitura correcta: "lê o valor actual de total, soma-lhe 10, e guarda o resultado de novo em total" • Em pseudocódigo PT usamos a seta ← para distinguir claramente da igualdade = • Em Python e na maioria das linguagens modernas usa-se = para atribuição e == para igualdade ❓ Perguntas para a turma • "Se total começa com 0 e executo 'total ← total + 5' três vezes, qual é o valor final?" • "Dêem 5 exemplos de coisas que devem ser CONSTANTES num programa de gestão de uma escola" • "Porque é que os nomes 'x', 'y', 'z' são maus na maioria dos casos?" 💡 Sugestões pedagógicas Usar a metáfora da gaveta: a variável é uma gaveta etiquetada onde se guarda algo. A atribuição é abrir a gaveta, tirar o que está lá, e meter algo novo. Esta imagem ajuda alunos visuais. ⏱️ Tempo estimado: 12 minutos

NOTAS DO PROFESSOR 📖 Conceito-chave: I/O e operadores LER e ESCREVER são instruções universais em pseudocódigo PT. Em Python tornam-se input() e print(). A precedência dos operadores segue a matemática: parênteses > potência > multiplicação/divisão > adição/subtracção. 🗣️ Pontos a desenvolver oralmente • DIV e MOD são fundamentais — usados constantemente (verificar paridade, converter unidades, distribuir igualmente) • Os operadores relacionais (=, ≠, <, >, ≤, ≥) produzem sempre um valor lógico • Os operadores lógicos (E, OU, NÃO) operam sobre valores lógicos — preparam o terreno para condições ❓ Perguntas para a turma • "Qual o resultado de 17 MOD 5? E de 17 DIV 5?" • "Como sabem se um número é par usando MOD?" • "(idade >= 18) E (carta_conducao = Verdadeiro) — quando é verdadeiro?" 💡 Sugestões pedagógicas Exercício no quadro: pedir aos alunos para escreverem expressões para coisas como "é maior de idade e tem carta" ou "tem dinheiro suficiente OU tem cartão de crédito". Discutir ambiguidades quando aparecem. ⏱️ Tempo estimado: 12 minutos

NOTAS DO PROFESSOR 📖 Teorema da Programação Estruturada (Böhm e Jacopini, 1966) Demonstrou-se matematicamente que qualquer algoritmo computável pode ser expresso usando apenas três estruturas de controlo: sequência, selecção (alternativa) e iteração (repetição). É a base teórica de toda a programação moderna. ⏱️ Tempo estimado: 1-2 minutos

NOTAS DO PROFESSOR 📖 Conceito-chave: Sequência A estrutura mais simples — o "default" da execução. A ordem importa: se calcularmos o IVA antes de termos o total, falhamos. 🗣️ Pontos a desenvolver oralmente • Apesar de simples, a sequência tem armadilhas: usar variável antes de a inicializar é um erro frequente • Algumas linguagens permitem optimizações que mudam a ordem aparente, mas isso é matéria avançada • A representação visual à direita já antecipa o fluxograma que veremos formalmente em breve ❓ Perguntas para a turma • "O que acontece se trocarmos a ordem dos LER pelos cálculos?" • "Conseguem ver o algoritmo da factura electrónica de um restaurante seguindo esta lógica?" • "Quantos passos sequenciais tem este algoritmo?" 💡 Sugestões pedagógicas Pedir aos alunos para acrescentarem um desconto antes do IVA. Discutir onde inserir, e porquê. Mostrar que pequenas mudanças de ordem alteram resultados. ⏱️ Tempo estimado: 8 minutos

NOTAS DO PROFESSOR 📖 Conceito-chave: Selecção (decisão) Segunda das três estruturas fundamentais. Permite que o algoritmo "ramifique" — execute caminhos diferentes consoante o valor de uma condição. 🗣️ Pontos a desenvolver oralmente • A condição tem sempre de produzir um valor lógico (Verdadeiro ou Falso) • O SENÃO é opcional — se não interessar fazer nada no caso Falso, omite-se • Em pseudocódigo PT a estrutura é SE...ENTÃO...SENÃO...FIM SE. Em Python é if...elif...else (sem fim explícito) • Quando há múltiplas condições mutuamente exclusivas, é mais legível usar uma estrutura de selecção múltipla (SWITCH/CASE) — veremos em UC seguinte ❓ Perguntas para a turma • "Escrevam um SE para classificar a nota: ≥10 'Aprovado', senão 'Reprovado'" • "Como classificariam: <10 reprovado, 10-13 sufic., 14-17 bom, ≥18 muito bom?" • "Que valor tem 'Verdadeiro E Falso'?" 💡 Sugestões pedagógicas Errar de propósito uma condição (>, ≥) e pedir à turma para detectar. Os casos limite são onde os bugs nascem — alimentar essa cultura de atenção desde cedo. ⏱️ Tempo estimado: 12 minutos

NOTAS DO PROFESSOR 📖 Conceito-chave: Iteração (repetição) Terceira das três estruturas fundamentais. Permite economizar instruções e processar quantidades arbitrárias de dados. ENQUANTO é mais geral (qualquer condição); PARA é mais específico (contador conhecido). 🗣️ Pontos a desenvolver oralmente • Existe também REPETIR...ATÉ (pós-teste — executa pelo menos uma vez) • A variável de controlo (i, j, k tradicionalmente, mas melhor nomes descritivos) • O conceito de "i = i + 1" como incremento — base do contador • Quando usar ENQUANTO: quando não se sabe à partida quantas iterações são necessárias (ler números até aparecer 0, ler até EOF, etc.) • Quando usar PARA: número de iterações conhecido (varrer uma lista de N elementos, gerar a tabuada do 7) ❓ Perguntas para a turma • "O ciclo PARA i DE 5 ATÉ 1 FAÇA executa? Quantas vezes?" • "Convertam o ENQUANTO ao lado num PARA equivalente" • "Como contam quantos números pares existem entre 1 e 100 usando um ciclo?" 💡 Sugestões pedagógicas Escrever um ciclo infinito propositadamente e perguntar: "como pararíamos isto?". Discussão: Ctrl+C, kill process, etc. — leva ao conceito de robustez e prevenção de ciclos infinitos. ⏱️ Tempo estimado: 15 minutos

NOTAS DO PROFESSOR 📖 Enquadramento Já vimos as estruturas; agora formalizamos a escrita. Pseudocódigo e fluxograma são complementares — o primeiro é textual, o segundo é visual. Bons programadores usam ambos consoante o problema. ⏱️ Tempo estimado: 1 minuto

NOTAS DO PROFESSOR 📖 Norma de pseudocódigo PT Não existe uma norma oficial única para pseudocódigo em Portugal — diferentes manuais usam variantes. A versão apresentada é a mais comum em manuais técnicos portugueses dos cursos profissionais (Editora Areal, Porto Editora). 🗣️ Pontos a desenvolver oralmente • O importante é a CONSISTÊNCIA dentro do mesmo trabalho — não misturar notações • Indentação não é decorativa — é fundamental para legibilidade • Comentários: usar // (linha) ou /* */ (bloco) por convenção • Em alguns ambientes (Portugol Studio, VisuAlg) o pseudocódigo é mesmo executável ❓ Perguntas para a turma • "Em que difere INICIO/FIM de SE/FIM SE?" • "Porque é que precisamos de palavras-chave (e não usamos só símbolos)?" • "Conhecem o Portugol Studio? Vamos usar mais à frente" 💡 Sugestões pedagógicas Apresentar 3-4 exemplos de pseudocódigo mal escrito (sem indentação, sem FIM, com palavras inventadas) e pedir à turma para corrigir. Discutir o que torna um pseudocódigo "limpo". ⏱️ Tempo estimado: 10 minutos

NOTAS DO PROFESSOR 📖 Caso integrador Este exemplo combina as três estruturas fundamentais: sequência (atribuições), iteração (PARA), selecção (SE encadeado). É também directamente relacionável com o sistema de avaliação que a turma vive. 🗣️ Pontos a desenvolver oralmente • Notar o uso de "soma" como acumulador — inicializada a 0, vai recebendo somas sucessivas • A variável "nota" é reutilizada — em cada iteração, recebe um valor novo • SE encadeado: a ordem dos testes importa — não se pode começar pelo "Insuficiente" • Discutir o problema dos limites: "media >= 18" vs "media > 17.5" — convencionalmente usa-se >= ❓ Perguntas para a turma • "Façam o trace deste algoritmo com notas 12, 15, 17, 13, 16" • "O que acontece se a turma tiver 6 alunos em vez de 5? Como adaptar?" • "E se quisermos pedir o número de notas ao utilizador?" 💡 Sugestões pedagógicas Exercício imediato (15 min): cada aluno reescreve o algoritmo para 10 notas em vez de 5, e acrescenta a contagem de quantas notas >= 14. Boa preparação para conceito de "acumulador + contador" que vamos formalizar no próximo bloco. ⏱️ Tempo estimado: 15 minutos

Processo

Decisão

I/O

Conector / setas

Subprocesso

NOTAS DO PROFESSOR 📖 Conceito-chave: Fluxograma (ISO 5807) Representação visual padronizada de um algoritmo usando símbolos geométricos. Cada símbolo tem significado específico, e a leitura faz-se de cima para baixo, esquerda para direita. 🗣️ Pontos a desenvolver oralmente • Os símbolos não são arbitrários — vêm de normas internacionais que datam dos anos 60 • Existe também o símbolo do "ciclo" (hexágono) usado por alguns autores, mas é menos comum • Para fluxogramas grandes, usa-se o "conector" (círculo com letra) para evitar setas que se cruzam • Hoje em dia, ferramentas como Draw.io, Lucidchart, Mermaid.js permitem desenhar fluxogramas digitalmente ❓ Perguntas para a turma • "Que símbolo usariam para 'enviar uma mensagem para o servidor'? (I/O ou Processo?)" • "E para 'verificar se o utilizador tem permissão'? (Decisão)" • "Porque é que a decisão tem 4 lados e o processo tem 4 lados também — qual é o distintivo?" 💡 Sugestões pedagógicas Mostrar exemplos de fluxogramas mal desenhados (setas que se cruzam, símbolos errados, sem terminal de fim) e pedir à turma para identificar os erros. Treina o olho crítico. ⏱️ Tempo estimado: 10 minutos

NOTAS DO PROFESSOR 📖 Equivalência das duas representações Pseudocódigo e fluxograma exprimem exactamente a mesma informação. A escolha entre um e outro é prática: pseudocódigo é mais rápido de escrever, fluxograma é mais intuitivo para mostrar a alguém que não programa. 🗣️ Pontos a desenvolver oralmente • Para algoritmos pequenos (até 20 instruções), o fluxograma é excelente • Para algoritmos grandes, o pseudocódigo é mais prático (o fluxograma fica ilegível) • Os fluxogramas continuam muito usados na documentação técnica, em arquitectura de sistemas e em UML • Em alguns projectos, exige-se o fluxograma como documentação obrigatória — saber desenhá-lo é competência profissional ❓ Perguntas para a turma • "Façam à mão (papel) o fluxograma e o pseudocódigo para: ler dois números e mostrar o maior" • "Qual das duas representações vos parece mais clara para este caso? E para um caso mais complexo, mudaria?" • "Como representariam um ciclo PARA num fluxograma?" (preparação para próxima discussão) 💡 Sugestões pedagógicas Pedir à turma para abrir o draw.io (online, gratuito) e reproduzir o fluxograma na ferramenta. Bom para a competência "Utilizar aplicações de representação diagramática" do referencial. ⏱️ Tempo estimado: 15 minutos

NOTAS DO PROFESSOR 📖 Enquadramento Estas técnicas são "tijolos" reutilizáveis em milhares de algoritmos. Identificá-las permite resolver problemas novos rapidamente — uma das competências da "abstração" do pensamento computacional. ⏱️ Tempo estimado: 1 minuto

NOTAS DO PROFESSOR 📖 Conceito-chave: Padrões de programação (programming patterns) Estes "micro-padrões" são as receitas básicas. Programadores experientes reconhecem-nos instantaneamente e aplicam-nos sem pensar. É exactamente a "Abstração + Reconhecimento de Padrões" do pensamento computacional aplicados na prática. 🗣️ Pontos a desenvolver oralmente • **Contador vs Acumulador:** contador soma sempre 1, acumulador soma um valor lido. Confusão comum • **Inicialização do produto:** se começamos com 0, qualquer produto dá 0 — daí 1 como elemento neutro • **Inicialização do máximo/mínimo:** truques: começar com o primeiro valor lido (evita -∞/+∞ mas obriga a tratar caso "lista vazia") • **Sentinela:** valor que SINALIZA o fim de uma sequência. Tem de ser distinguível dos valores válidos • **Validação:** REPETIR-ATÉ é o ciclo natural para validar — executa pelo menos uma vez ❓ Perguntas para a turma • "Que padrão usariam para calcular o factorial de N?" (acumulador-produto) • "E para contar quantas vezes a letra 'A' aparece num texto?" (contador) • "Que valor de sentinela escolheriam para parar uma leitura de idades positivas?" (-1, 0 ou outro) • "Porquê 'REPETIR' e não 'ENQUANTO' para validar?" (pré vs pós-teste) 💡 Sugestões pedagógicas Distribuir uma folha com 10 problemas pequenos e pedir à turma para identificar qual o padrão dominante em cada. Discutir respostas. É excelente exercício de meta-cognição (pensar sobre como pensamos). ⏱️ Tempo estimado: 15 minutos

NOTAS DO PROFESSOR 📖 Enquadramento Bloco mais prático da UC. Cada caso vai ser apresentado em duas representações (pseudocódigo + Python) para tornar a transição para programação real mais suave. ⏱️ Tempo estimado: 1 minuto

NOTAS DO PROFESSOR 📖 Caso clássico Algoritmo do "máximo numa sequência" é um dos primeiros em qualquer manual. Demonstra o padrão "máximo" e a iteração indexada. 🗣️ Pontos a desenvolver oralmente • Porquê começar com o primeiro? Alternativa seria inicializar maior com -infinito, mas é mais elegante usar o primeiro elemento real • Note-se o "range(2, n + 1)" em Python — começa em 2 porque já lemos o primeiro fora do ciclo • A solução é O(n) — uma só passagem pelos dados. Não há forma de fazer melhor ❓ Perguntas para a turma • "E se quisermos saber também a POSIÇÃO do maior?" (acrescentar variável pos_maior) • "E se quisermos os 3 maiores?" (problema mais complexo — discutir abordagens) • "E se a lista estiver vazia (n=0)? O que acontece?" (caso limite — debate) 💡 Sugestões pedagógicas Executar o programa Python em directo. Trazer um exemplo com valores reais (notas de teste, classificações, etc.) para tornar relatable. ⏱️ Tempo estimado: 12 minutos

NOTAS DO PROFESSOR 📖 Caso integrador Algoritmo mais ambicioso. Combina sentinela, contador, acumulador e validação. Também demonstra a importância de tratar o caso limite "nenhuma nota válida" (evita divisão por zero). 🗣️ Pontos a desenvolver oralmente • A "ler antes do ciclo + ler dentro do ciclo" é um padrão clássico para sentinela com ENQUANTO. Em alternativa, usaríamos REPETIR-ATÉ • A validação aqui está dentro do mesmo ciclo — alternativa seria validar com sub-ciclo • Divisão por zero: protecção essencial. Em Python lançaria excepção; em pseudocódigo seria comportamento indefinido ❓ Perguntas para a turma • "E se a sentinela fosse uma nota válida (ex: 0)? Que problema haveria?" • "Como tornariam a validação mais robusta — exigir que o utilizador insira sempre uma nota válida?" (REPETIR-ATÉ) • "Façam o trace para: 14, -5, 17, 25, 12, -1" 💡 Sugestões pedagógicas Discutir alternativas de design: pedir N à partida vs usar sentinela — qual é melhor? Depende do contexto. Esta discussão prepara conceito de "robustez" e "design defensivo" que veremos em UCs mais avançadas. ⏱️ Tempo estimado: 18 minutos

NOTAS DO PROFESSOR 📖 Meta-aprendizagem A capacidade de identificar padrões NO PRÓPRIO TRABALHO é uma marca distintiva entre programador júnior e sénior. Treinar este reconhecimento desde o início é dos investimentos pedagógicos mais altos. 🗣️ Pontos a desenvolver oralmente • Ao longo da UC, sempre que aparecer um problema novo, perguntar primeiro: "o que disto já vimos?" • Os padrões são INDEPENDENTES da linguagem — funcionam em Python, C, Java, JavaScript • Esta UC fornece as "letras"; UCs futuras combinam-nas em "palavras" (programas) ❓ Perguntas para a turma • "Qual destes padrões acharam mais difícil de entender? Porquê?" • "Conseguem propor um padrão NOVO que ainda não vimos?" (talvez troca/swap, ordenação básica) ⏱️ Tempo estimado: 5 minutos

NOTAS DO PROFESSOR 📖 Enquadramento Esta é a quinta e última realização da UC. Saber escrever algoritmos é metade do trabalho; saber testá-los e corrigi-los é a outra metade. Os profissionais passam muito mais tempo a depurar do que a escrever. ⏱️ Tempo estimado: 1 minuto

NOTAS DO PROFESSOR 📖 Conceito-chave: Trace Table (Tabela de execução) Ferramenta manual de simulação. Permite "executar" o algoritmo no papel, registando o valor de cada variável após cada instrução. É a forma mais eficaz de depurar sem computador. 🗣️ Pontos a desenvolver oralmente • Para algoritmos curtos, a trace table é a melhor ferramenta de depuração • Em ambientes de programação reais existem debuggers visuais que fazem o mesmo automaticamente • A coluna "Observação" é onde notamos comportamentos suspeitos — útil para encontrar bugs ❓ Perguntas para a turma • "Façam a trace table para o factorial de 5" • "Façam a trace table para o algoritmo da média (caso 2 anterior) com entradas: 10, 14, 16, -1" • "Se removermos a inicialização fact ← 1, o que aconteceria?" 💡 Sugestões pedagógicas Pedir à turma para fazer a trace table de um algoritmo COM BUG (ex: ciclo PARA de 1 a n mas a inicializar fact ← 0). Eles próprios descobrem o erro através da tabela. Eureka pedagógico. ⏱️ Tempo estimado: 15 minutos

NOTAS DO PROFESSOR 📖 Conceito-chave: Bugs e debugging A palavra "bug" vem literalmente de um insecto que ficou preso num relé do Mark II em 1947 (Grace Hopper documentou). Hoje refere-se a qualquer erro num programa. Depurar (debug) é encontrar e corrigir bugs. 🗣️ Pontos a desenvolver oralmente • Os erros mais frequentes nunca são os mais espectaculares — são pequenos descuidos (>, < ; = , ==) • Off-by-one é tão frequente que tem nome próprio em inglês • Sempre testar com CASOS LIMITE: lista vazia, valor zero, valor negativo, valor enorme • "Programação defensiva" = assumir que o pior pode acontecer e proteger ❓ Perguntas para a turma • "Identifiquem o tipo de erro: o algoritmo conta 11 alunos numa turma de 10" • "Identifiquem: o algoritmo nunca pára quando a lista está vazia" • "Identifiquem: o algoritmo dá média = 0 quando todas as notas eram 20" 💡 Sugestões pedagógicas Mostrar 5 mini-algoritmos com bugs e a turma vota o tipo. Pode-se transformar em jogo. Posteriormente, corrigir cada um e discutir alternativas. ⏱️ Tempo estimado: 15 minutos

NOTAS DO PROFESSOR 📖 Conceito-chave: Optimização Optimização tem dois aspectos: macro (complexidade algorítmica — matéria de UC futura) e micro (boas práticas de escrita). Nesta UC focamos a parte micro. 🗣️ Pontos a desenvolver oralmente • A citação de Knuth é fundamental: NÃO optimizar antes de saber se precisa. Primeiro escrever código que funciona e é legível • Optimizar para performance só faz sentido se: 1) o código for lento; 2) tivermos medido onde está a lentidão • Optimizar para legibilidade é SEMPRE válido — código lido muitas mais vezes do que escrito • Os nomes de variáveis são o primeiro nível de optimização da legibilidade ❓ Perguntas para a turma • "Qual destas estratégias acham mais difícil de aplicar?" • "Conseguem dar um exemplo de comentário que ajuda — e outro que prejudica?" • "Vale a pena optimizar um algoritmo que corre 1 vez por mês?" 💡 Sugestões pedagógicas Mostrar o mesmo algoritmo escrito de 3 formas: minimalista (1 letra por variável, sem comentários), verboso (excesso de comentários), equilibrado. Discutir qual é "melhor". Não há resposta única — depende do contexto. ⏱️ Tempo estimado: 12 minutos

NOTAS DO PROFESSOR 📖 Enquadramento Última secção. Consolidação e ligação às próximas UCs do curso. ⏱️ Tempo estimado: 1 minuto

5 nós satélite

NOTAS DO PROFESSOR 📖 Síntese visual O mapa concetual organiza visualmente as cinco grandes áreas que cobrimos: pensamento computacional como enquadramento, conceito de algoritmo, blocos básicos (dados+estruturas), representações (pseudo+fluxo), e ciclo de construção+teste. 🗣️ Pontos a desenvolver oralmente • Cada um destes ramos podia ser uma UC por si — aqui condensámo-los porque são os fundamentos • A próxima UC do curso (UC02829 "Instalar, configurar e parametrizar sistemas operativos" no TDS ou outras de programação) vai assumir TUDO isto • Recomendar revisão activa: pegar no mapa e tentar explicar oralmente cada nó ao colega (técnica de Feynman) ❓ Perguntas para a turma • "Conseguem explicar com vossas palavras o que conecta 'Pensamento computacional' a 'Algoritmo'?" • "Qual destes 5 nós sentem que precisam de mais prática?" • "Como avaliariam o vosso nível de cada um numa escala de 1-4?" 💡 Sugestões pedagógicas Distribuir o mapa em branco (só com a estrutura) e pedir aos alunos para preencherem. Excelente ferramenta de avaliação formativa rápida. ⏱️ Tempo estimado: 10 minutos

NOTAS DO PROFESSOR 📖 Enquadramento curricular Importante mostrar à turma que esta UC não é um fim em si — é o ponto de partida. Tudo o que aprenderam aqui vai ser RE-utilizado e EX-pandido nas próximas UCs. 🗣️ Pontos a desenvolver oralmente • Reforçar que dominar BEM esta UC poupa muito sofrimento nas próximas • Os recursos extra são para alunos curiosos — não obrigatórios, mas altamente recomendados • Portugol Studio é especialmente útil para quem quer praticar pseudocódigo "à séria" (executável) ❓ Perguntas para a turma • "Qual destes recursos extra vos parece mais interessante explorar?" • "Que dúvidas ainda têm desta UC que querem clarificar antes do teste?" • "O que gostariam de saber programar a seguir?" (Web? Apps? Jogos?) 💡 Sugestões pedagógicas Esta é a última aula antes da avaliação. Reservar tempo para Q&A aberto. Convidar alunos avançados a partilhar projectos pessoais que já façam. ⏱️ Tempo estimado: 10 minutos

NOTAS DO PROFESSOR 📖 Slide final Reservar para Q&A. Recolher feedback informal sobre o que correu bem e o que pode melhorar nesta UC. 🗣️ Pontos a desenvolver oralmente • Agradecer atenção • Lembrar do calendário de avaliação • Convidar a partilhar erros ou sugestões para os slides (foram gerados a partir do referencial oficial — qualquer melhoria é integrada) ⏱️ Tempo estimado: 5-10 minutos