Laboratório de Desenho e Teste de Software
Desenhar, testar e evoluir aplicações Java, de um objeto pequeno à arquitetura de um projeto.
Uma arena com cinco células basta para discutir desenho de software: quem aceita o movimento, quem mostra a posição e que teste deteta um limite errado? O percurso desenvolve este jogo em Java, separando responsabilidades e verificando contratos antes de mudar a estrutura.
Parte do que já sabes de programação, incluindo funções, condições e coleções. Não precisas de decorar padrões antes de começar. Primeiro identifica o problema, depois percebe que colaboração entre objetos o resolve. O herói move-se, soma pontos e guarda o resultado. Quando a loja introduz preços, seguimos a mesma tarifa ao extrair e simplificar a regra. Os exemplos são pequenos e próprios; não constituem um projeto completo nem um enunciado docente.
Percurso de estudo
- Git e Gradle: distinguir o ficheiro editado, o conteúdo preparado e o commit; reproduzir um build.
- Java orientado a objetos: proteger invariantes, usar interfaces e escolher coleções e genéricos.
- Concorrência, I/O e Swing: coordenar threads, fechar recursos e responder a eventos sem bloquear a interface.
- Princípios SOLID: justificar as dependências e reconhecer contratos que uma subclasse viola.
- Testes unitários: escolher casos, verificar resultados e interpretar cobertura e mutação.
- UML: relacionar estrutura, mensagens e estados com o código.
- Smells e refactoring: melhorar o desenho em passos que preservam o comportamento.
- Padrões de desenho: escolher e aplicar os dez padrões do programa.
- MVC e projeto: seguir um evento do utilizador e testar o modelo sem a interface.
- Arquitetura empresarial: separar regras, operações da aplicação e persistência.
Os exercícios são próprios ou adaptações atribuídas de problemas históricos e aparecem no fim da lição que os prepara. Tenta responder antes de abrir as pistas. A cheat sheet serve para rever condições e diferenças depois da primeira leitura.
Como praticar
Depois de um exemplo, muda uma condição e prevê o resultado antes de o executar. Para uma hierarquia, escreve um cliente da interface e verifica se todas as implementações cumprem o mesmo contrato. Para uma refatoração, descreve primeiro o comportamento que deve continuar igual.
No projeto, trabalha por comportamentos completos: um evento, uma alteração válida do modelo, um resultado visível e os testes correspondentes. Um diagrama pequeno da interação ajuda mais do que um desenho com todas as classes sem uma pergunta concreta.
Avaliação em 2026/27
A ficha oficial da ocorrência 586992 indica avaliação distribuída sem exame final:
| Componente | Peso na classificação final |
|---|---|
| Participação nas aulas práticas | 5% |
| Projeto integrado, em grupos de três | 55% |
| Primeira prova individual em computador | 20% |
| Segunda prova individual em computador | 20% |
Todas as componentes têm classificação mínima de 40%. A classificação do projeto resulta de 10% do relatório intermédio, 30% do relatório final e 60% do produto. Estes pesos são internos ao projeto; por exemplo, o produto corresponde a da classificação final. O relatório deve fundamentar o contributo individual de cada elemento.
A frequência exige respeitar o limite de faltas às aulas teórico-práticas, participar no projeto e submetê-lo segundo as indicações da unidade curricular. A ficha não quantifica aqui esse limite. A época de recurso inclui apenas as duas provas individuais em computador.
Todas as componentes são obrigatórias também para estudantes com estatutos especiais. Quem está dispensado de frequentar as aulas entrega nas mesmas datas e apresenta regularmente aos docentes a evolução do trabalho. Confirma datas, formato das provas e instruções de entrega no Moodle da tua edição.
Fontes para aprofundar: bibliografia, âmbito e referências de API
O programa e a avaliação acima seguem a ficha de 2026/27. As explicações usam as apresentações públicas de André Restivo, em particular Java, Git, SOLID, testes, refactoring, padrões e UML, e os seus exemplos Hero e Design Patterns Hero. As apresentações públicas não identificam uma edição académica. O arquivo Moodle 2026/27 consultado não contém materiais de ensino de LDTS; o curso acessível de 2025/26 não disponibilizava semanas, projeto nem provas. Os programas destas páginas são exemplos próprios e reduzidos.
O arquivo histórico do Accio acrescenta um questionário contribuído por estudante, identificado como 2022 no nome do ficheiro, sem data visível que confirme a edição académica, e provas teóricas com datas de 2012 a 2017. Os projetos de treino Event, Act, Flavor e Pizza são identificados nas pastas como 2018 a 2021; os seus testes não datam por si só a edição. A prática aproveita objetivos desses materiais, com exemplos novos, sem os apresentar como formato ou matéria garantidos das provas atuais.
A coleção 3-numbers, na pasta de resoluções das práticas, treina ordenar, filtrar, eliminar duplicados e distinguir casos de regressão com substitutos de dependências. Não tem um ano académico confirmado nos ficheiros consultados. As respostas históricas e de estudantes são apoio para escolher problemas, não uma autoridade sobre regras de Java: as soluções destas páginas são conferidas por compilação e execução.
A bibliografia obrigatória é Thinking in Java, de Bruce Eckel, 4.ª edição ou superior, e Learning UML 2.0, de Russ Miles e Kim Hamilton. A ficha recomenda também Test-Driven Development, de Kent Beck; Design Patterns, de Gamma, Helm, Johnson e Vlissides; Refactoring, de Martin Fowler; Agile Software Development: Principles, Patterns, and Practices, de Robert C. Martin; e Building Maintainable Software, de Joost Visser.
A ficha enumera os dez padrões de desenho, mas não detalha os padrões de arquitetura empresarial. Nessa lição, a seleção do catálogo de Fowler serve de complemento; não confirma quais serão exigidos nas provas.
Para consultar APIs e contratos:
- Java Tutorials, Oracle: coleções, genéricos, concorrência, I/O e Swing. Os exemplos executáveis aqui usam Java 8.
- Java Language Specification, SE8: regras de tipos, apagamento e avaliação de expressões. O guia de assertions explica quando a instrução
asserté executada. - Manual do Git e Pro Git: índice, branches, remotos e integração.
- Gradle, projetos Java: tarefas, dependências e wrapper.
- JUnit 5.13.4 e Mockito: testes e substitutos de dependências. Os exemplos locais fixam as versões para poderes reproduzi-los.
- PIT, plugin Gradle e integração JUnit 5: testes de mutação e compatibilidade das ferramentas.
- Catálogo de refatorações de Martin Fowler e Patterns of Enterprise Application Architecture: mudanças de estrutura e separação de responsabilidades.
Vídeos para acompanhar
Barbara Liskov, How data abstraction changed computing ajuda a perceber por que um tipo se define pelo que promete aos clientes. Ao ver, distingue esconder a representação de escolher os valores e operações válidos. Relaciona essa ideia com o exemplo de substituição em SOLID.
Os vídeos seguintes vivem nas lições dos conceitos que visualizam:
- Branches e merges: criar branches e integrá-las sem perder commits.
- Princípios SOLID: responsabilidades e contratos em Java.
- Testes unitários: resultados com JUnit e dependências com Mockito.
- Smells e refactoring: encontrar uma razão para mudar.
- Observer: subscrever, notificar e sair.