Desafio Profissional POO

Prévia do material em texto

TEMPLATE PADRÃO ÚNICO DO DESAFIO PROFISSIONAL 
 
ORIENTAÇÕES IMPORTANTES ANTES DE COMEÇAR: 
 
Este é o template padrão único para a realização do seu Desafio Profissional. Para todas as 
disciplinas, o template será o mesmo. O que muda é a proposta do seu desafio. 
Portanto, para que você conheça o desafio proposto para a sua disciplina, é preciso: 
1) Acessar o seu AVA; 
2) Clicar na disciplina que será avaliada; 
3) Entrar em “Notas e Avaliações”; 
4) Clicar em “Responder Avaliação III”. 
 
Além disto, é fundamental que você faça a leitura atenta da questão na íntegra antes de 
iniciar o preenchimento deste template. 
 
Agora, vamos às etapas de realização do seu desafio profissional. 
 
ETAPA 1: Apresentação do Desafio Profissional 
Seu papel ativo nesta etapa é apenas ler tudo com atenção e entender qual solução (ou 
soluções) você apresentará ao final da atividade. Então, leia todas as orientações da Etapa 
1 do seu Desafio Profissional. 
 
ETAPA 2: Materiais de referência (ambientação) do seu Desafio Profissional 
Nesta etapa, você deve analisar os materiais de referência e eleger três aspectos mais 
relevantes na solução do desafio. Por exemplo: uma estratégia inovadora, uma decisão 
polêmica ou uma atitude inesperada. Seu papel ativo nesta etapa é apontar esses três 
aspectos e justificar suas escolhas. 
 
Estudante, escreva aqui os três aspectos e justifique suas escolhas. Anote assim 
neste template: o que chamou atenção + por quê. 
Aspecto 1: Pilares da Programação Orientada a Objetos (Encapsulamento, Herança, 
Polimorfismo e Abstração). 
 
Justificativa: Os pilares da POO oferecem a estrutura conceitual necessária para 
decompor o domínio em classes e objetos com responsabilidades bem definidas. A 
abstração orienta a seleção dos elementos relevantes. O encapsulamento protege o 
estado e centraliza regras. A herança permite especialização controlada. O polimorfismo 
favorece extensibilidade sem alterar clientes. Aplicados ao sistema de organização de 
estudos, esses pilares orientam decisões como a modelagem de Tarefa (encapsulamento 
do status e regras de alteração) e a opção por heranças simples (por exemplo, Usuario → 
Aluno/Tutor) apenas quando houver justificativa funcional. 
 
Fontes: FIAP (artigo sobre pilares POO); 
 
Aspecto 2: Identificação e modelagem de classes (análise de domínio) 
Justificativa: A eficácia da modelagem orientada a objetos depende da identificação 
correta das entidades e da definição precisa de suas responsabilidades no domínio, pois 
falhas nessa etapa ampliam o gap semântico e favorecem retrabalho. Para conduzir essa 
modelagem, é necessário extrair classes a partir dos requisitos e dos casos de uso, 
definindo para cada uma seus atributos essenciais, operações públicas e limites de 
responsabilidade. No projeto proposto, essa orientação fundamenta a escolha das 
classes centrais, como Usuário, Disciplina, Tarefa e Progresso, além de contribuir para a 
delimitação de seus papéis, evitando classes com funções excessivas e favorecendo 
maior coesão e menor acoplamento. 
 
Fontes: CIN/UFPE (Introdução ao Projeto Orientado a Objeto); 
 
Aspecto 3: Diagramas UML como instrumento de documentação e comunicação 
Justificativa: O Diagrama de Classes UML é importante porque torna visível a estrutura da 
solução proposta, reduzindo ambiguidades sobre responsabilidades e relacionamentos 
entre as classes. Em um cenário no qual o desenvolvimento foi iniciado sem uma 
modelagem prévia, essa representação contribui diretamente para alinhar o entendimento 
técnico da equipe e diminuir retrabalho. Além disso, o diagrama permite visualizar 
atributos, métodos, cardinalidades e tipos de relacionamento, funcionando como um 
recurso de documentação e apoio à implementação. 
 
 
Fontes: Tecgraf/PUC-Rio (modelagem orientada a objetos); 
 
ETAPA 3: Levantamento de conceitos teóricos 
Aqui, você deve aproximar a teoria da prática. Seu papel ativo nesta etapa é pesquisar 
conceitos, autores, teorias etc., que possibilitem a compreensão da solução do desafio. 
Para isto, faça uma lista comentada de conceitos-chave, cada um explicado em duas ou 
três linhas. Por exemplo: Nome do conceito → definição curta → como ajuda a entender o 
caso. Lembre-se de que é como montar uma “maleta de ferramentas teóricas” para usar 
na próxima etapa. 
 
Orientação a Objetos → Paradigma de desenvolvimento que organiza software em classes 
e objetos, cada um combinando estado (atributos) e comportamento (métodos). → Como 
ajuda: permite representar diretamente as entidades do domínio (Usuário, Disciplina, 
Tarefa), facilitando a decomposição do sistema em unidades coesas e compreensíveis. 
 
Abstração → Processo de selecionar apenas as características relevantes de uma 
entidade, omitindo detalhes desnecessários. → Como ajuda: define quais atributos e 
operações são essenciais para Disciplina e Tarefa, mantendo o modelo focado no que 
importa para organizar estudos. 
 
Encapsulamento → Técnica de proteger o estado interno de um objeto tornando atributos 
privados e expondo operações controladas. → Como ajuda: garante que mudanças em 
Tarefa (ex.: status, datas) ocorram por métodos específicos (marcarComoConcluida()), 
preservando invariantes e evitando uso indevido dos dados. 
 
Herança → mecanismo que permite a especialização de uma classe a partir de outra, 
reaproveitando atributos e comportamentos comuns. → Como ajuda: mostra que a 
herança só deve ser utilizada quando houver uma especialização real no domínio, evitando 
estruturas artificiais e desnecessárias no modelo. 
 
 
Polimorfismo → Capacidade de diferentes classes responderem a um mesmo contrato 
(interface/assinatura) com implementações específicas. → Como ajuda: permite, por 
exemplo, trocar estratégias de notificação (email, push) por meio de uma interface 
comum, sem alterar o código que solicita a notificação. 
 
Associação / Agregação / Composição → representam diferentes formas de vínculo entre 
classes, variando conforme o grau de dependência entre os objetos. → Como ajuda: 
permite compreender como as entidades do sistema se relacionam e até que ponto uma 
depende da outra, como ocorre na relação entre Disciplina e Tarefa. 
 
Cardinalidade e Navegabilidade → Cardinalidade indica quantas instâncias se 
relacionam (1..1, 0..*); navegabilidade define em que direção a relação pode ser 
percorrida. → Como ajuda: formaliza regras como Usuario 1 — * Disciplina e Disciplina 1 
— * Tarefa, permitindo projetar consultas e interfaces coerentes com o fluxo de dados do 
sistema. 
 
Diagrama de Classes UML → Representação visual padronizada de classes, atributos, 
métodos, visibilidades e relacionamentos (com cardinalidades). → Como ajuda: 
documenta o modelo de forma clara para avaliadores e desenvolvedores, servindo de 
referência para justificar escolhas (por exemplo, composição entre Disciplina e Tarefa) e 
reduzir o gap semântico. 
 
Coesão e Baixo Acoplamento → coesão refere-se ao grau em que os elementos de uma 
classe contribuem para uma única finalidade, enquanto baixo acoplamento indica menor 
dependência entre classes. → Como ajuda: esses princípios explicam por que a divisão 
adequada de responsabilidades torna o sistema mais organizado, mais fácil de manter e 
menos sujeito a retrabalho. 
 
ETAPA 4: Aplicação dos conceitos teóricos ao Desafio Profissional 
Neste momento, você deve começar a construção da sua análise. É aqui que você vai usar 
sua “maleta de ferramentas” para solucionar o desafio. Seu papel ativo nesta etapa é 
 
aplicar cada conceito que julgue importante e conectá-lo com algo que acontece na 
situação analisada. Você fará isso por meio de uma lista de tópicos, respondendo: 
• Como o conceito X explica o que aconteceu na situação Y? 
• O que a teoria X nos ajuda a entender sobre o problema central? 
• Que soluções possíveis a teoria aponta (e por que elas fazemsentido)? 
 
1) Orientação a Objetos 
Como explica o problema: sem modelagem OO, o código vira um amontoado de funções 
e dados soltos, é normal surgir duplicação e confusão de responsabilidades. 
O que ajuda a entender: OO nos lembra que sistemas complexos ficam controláveis 
quando divididos em unidades (classes) que encapsulam dados e comportamento. 
Solução prática: reorganizar o projeto a partir das entidades do domínio: Usuario, 
Disciplina, Tarefa, Progresso. Documentar cada responsabilidade e usar o diagrama de 
classes como “contrato” entre quem modela e quem implementa. 
 
2) Abstração 
Como explica o problema: muitas vezes foram implementadas propriedades irrelevantes 
ou misturadas na mesma estrutura, o que confunde o propósito das entidades. 
O que ajuda a entender: abstração ensina a manter só o que importa para a 
funcionalidade prevista. 
Solução prática: definir, para cada classe, apenas os atributos e métodos essenciais. Ex.: 
Tarefa precisa de titulo, dataVencimento, prioridade, status e métodos como 
marcarComoConcluida() e ehAtrasada(), nada além do necessário para organizar estudos. 
 
3) Encapsulamento 
Como explica o problema: quando qualquer parte do sistema altera diretamente o estado 
(por exemplo, muda status de tarefa sem regras), surgem inconsistências. 
O que ajuda a entender: encapsular coloca um “porteiro” entre o estado e quem o 
manipula, mudanças passam por métodos que validam regras. 
 
 
Solução prática: tornar atributos privados e expor operações de domínio (em vez de só 
getters/setters). Assim Tarefa.marcarComoConcluida() pode checar pré-requisitos antes 
de mudar o status. 
 
4) Responsabilidade Única (Coesão) 
Como explica o problema: classes que fazem muitas coisas são difíceis de entender e 
testar. Isso é uma fonte direta de retrabalho. 
O que ajuda a entender: dividir responsabilidades torna cada classe simples e com 
propósito claro. 
Solução prática: reorganizar responsabilidades: Tarefa cuida apenas de regras da 
tarefa; Disciplina agrega tarefas e calcula progresso; Progresso guarda histórico. Separar 
lógica de persistência e de apresentação. 
 
5) Baixo Acoplamento 
Como explica o problema: acoplamento alto transforma pequenas mudanças em efeitos 
em cadeia. 
O que ajuda a entender: quanto menos dependências diretas entre classes, mais fácil 
evoluir o sistema. 
Solução prática: comunicar por contratos (interfaces) e por identificadores (disciplinaId, 
usuarioId) em vez de chamadas diretas às implementações; usar repositórios e serviços 
para isolar acessos a dados. 
 
6) Herança (uso com critério) 
Como explica o problema: hierarquias mal planejadas complicam mais do que ajudam. 
O que ajuda a entender: herança é útil quando há uma relação clara de “é-um”; caso 
contrário, composições e interfaces são melhores. 
Solução prática: manter Usuario genérico e só criar Aluno/Tutor se realmente houver 
comportamentos novos a implementar (por exemplo, Tutor.moderaDisciplina()). 
 
7) Polimorfismo (flexibilidade por contrato) 
Como explica o problema: soluções monolíticas (ex.: notificação hardcoded) tornam o 
sistema rígido. 
 
O que ajuda a entender: polimorfismo permite trocar estratégias sem mexer no código 
que as consome. 
Solução prática: definir Notificavel e ter implementações como EmailNotifier e 
PushNotifier; o sistema chama notificar() e não precisa saber qual é a implementação. 
 
8) Relacionamentos: Associação, Agregação e Composição 
Como explica o problema: não deixar claro quem “é dono” de que gera objetos órfãos e 
inconsistência no ciclo de vida. 
O que ajuda a entender: escolher o tipo certo de relacionamento evita surpresas ao 
excluir ou migrar entidades. 
Solução prática: modelar Disciplina → Tarefa como composição (tarefas existem dentro 
da disciplina); Usuario → Disciplina como associação (um usuário tem disciplinas, mas a 
gestão de vida pode ser independente). 
 
9) Cardinalidade e Navegabilidade 
Como explica o problema: sem especificar quantidades/direções, telas e APIs ficam 
ambíguas. 
O que ajuda a entender: cardinalidade e navegabilidade guiam consultas, telas e decisões 
de carregamento de dados. 
Solução prática: definir Usuario 1 — * Disciplina e Disciplina 1 — * Tarefa, com navegação 
principal Usuario → Disciplina → Tarefa; isso orienta endpoints e views. 
 
10) Diagrama de Classes UML (documento de referência) 
Como explica o problema: ausência de um artefato visual deixa decisões implícitas e 
sujeitas a interpretações diferentes. 
O que ajuda a entender: o diagrama padroniza visibilidade, relacionamentos e 
responsabilidades. 
Solução prática: entregar um diagrama com atributos (-), métodos (+) e cardinalidades 
visíveis; usar o diagrama como base para revisão com a equipe antes da implementação. 
 
11) Progresso e histórico (caso prático) 
Como explica o problema: armazenar só o estado atual perde rastreabilidade. 
 
O que ajuda a entender: separar estado atual de histórico permite relatórios e análise de 
comportamento de estudo. 
Solução prática: criar Progresso com tarefaId, usuarioId, percentual, dataAtualizacao; 
Disciplina.calcularProgresso() agrega para apresentar um panorama do desempenho. 
 
12) Validações e tratamento de exceções 
Como explica o problema: regras espalhadas deixam entradas inválidas passarem e 
geram erros em produção. 
O que ajuda a entender: centralizar validações no domínio evita estados inválidos e 
facilita feedback ao usuário. 
Solução prática: validar na criação/atualização (ex.: dataVencimento não pode ser 
anterior à criação); lançar exceções específicas e retornar erros amigáveis pela API. 
 
13) Separação de camadas (arquitetura simples e testável) 
Como explica o problema: mistura de lógica e persistência torna difícil testar e modificar 
o sistema. 
O que ajuda a entender: separar domínio, serviços, repositórios e interface melhora 
manutenção. 
Solução prática: criar TarefaService, DisciplinaRepository, etc., onde cada camada tem 
responsabilidade clara. 
 
O modelo proposto foi representado por meio de um Diagrama de Classes UML, com o 
objetivo de demonstrar visualmente as classes principais do sistema, seus atributos, 
métodos e relacionamentos. Essa representação contribui para a organização da solução, 
facilita a compreensão da estrutura do sistema e reduz ambiguidades durante o 
desenvolvimento.
 
O diagrama evidencia a distribuição das responsabilidades entre as classes Usuário, 
Disciplina, Tarefa e Progresso, bem como os relacionamentos estabelecidos entre elas. 
 
Com essa modelagem, o sistema se torna mais organizado, compreensível e preparado 
para futuras manutenções e evoluções. 
 
A ETAPA 5 É A MAIS IMPORTANTE DE TODO O PROCESSO, POIS É A ETAPA QUE SERÁ 
AVALIADA! ENTÃO, PRESTE MUITA ATENÇÃO! 
 
ETAPA 5 – AVALIATIVA: Redação do produto - Memorial Analítico. 
Chegou a hora de transformar todo o seu percurso investigativo em um texto claro, bem 
estruturado e objetivo. Seu papel ativo nesta etapa é desenvolver um Memorial 
Analítico. Este será o produto final do Desafio Profissional, que será avaliado com nota de 
zero a dez e terá peso três na média final desta disciplina. 
 
Vamos reforçar o que é um memorial analítico? É basicamente você mostrando o 
caminho que percorreu: o que leu, como interpretou, que teorias usou, que conclusões 
tirou e o que aprendeu com tudo isso. 
Para ajudar você, segue o passo a passo do que não pode faltar no Memorial Analítico 
(ordem recomendada, pois cada item fará parte da composição da sua nota): 
 
• Resumo do que você descobriu (1 parágrafo) – vale 1 ponto 
• Contextualização do desafio (1 parágrafo): Quem? Onde? Qual a situação? – vale 
0,5 ponto 
• Análise (1 parágrafo): use de 2 a 3 conceitos da disciplina, mostrando como eles 
explicam a situação. Dê exemplos diretos e contextualizados – vale 2 pontos 
• Propostas de solução (até 2 parágrafos): o que você recomenda?Por quê? Qual 
teoria apoia sua ideia? – vale 3 pontos 
• Conclusão reflexiva (até 2 parágrafos): O que você aprendeu com essa 
experiência? – vale 2 pontos 
• Referências (somente o que você realmente usou, incluindo o livro) – vale 0,5 
ponto 
• Autoavaliação (1 parágrafo): o que você percebeu sobre seu próprio processo de 
estudo? – vale 1 ponto 
 
 
Checklist rápido antes de entregar: 
• Meu texto não passou de 6000 caracteres. 
• Meus conceitos fazem sentido, e não estão só “porque sim”. 
• Conectei teoria + situação. 
• Apresentei soluções plausíveis. 
• Incluí referências. 
• Mostrei que aprendi algo. 
• Tenho orgulho do que escrevi. 
Lembre-se de que este trecho deve ser copiado e colado no campo de resposta da 
questão, dentro de Notas e Avaliações. 
Lembre-se também de salvar este documento em PDF e colocá-lo como anexo à sua 
resposta. 
Ao desenvolver este desafio, percebi que o principal problema da equipe não estava 
apenas na programação, mas na falta de uma modelagem orientada a objetos definida 
desde o início. A análise mostrou que, sem classes bem estruturadas, responsabilidades 
claras e relacionamentos adequados, o sistema tende a gerar retrabalho, inconsistências 
e dificuldade de manutenção. A principal descoberta foi que a orientação a objetos 
funciona como base de organização do projeto, dando mais clareza à solução e facilitando 
sua evolução. 
 
O caso analisado envolve uma startup de tecnologia educacional que está criando uma 
plataforma web de organização de estudos para estudantes de cursos EaD. A plataforma 
deve permitir cadastro de usuários, disciplinas, tarefas com datas e prioridades, além do 
acompanhamento do progresso dos estudos. Entretanto, o time iniciou o desenvolvimento 
sem um modelo orientado a objetos consolidado, o que gerou falta de clareza sobre as 
responsabilidades das classes e comprometeu a organização do sistema. 
 
Essa situação pode ser explicada, principalmente, pelos conceitos de abstração, 
encapsulamento e relacionamentos entre classes. A abstração permitiu identificar os 
elementos centrais do domínio, representados pelas classes Usuário, Disciplina, Tarefa e 
Progresso, evitando uma solução genérica e desorganizada. O encapsulamento mostrou a 
 
importância de concentrar atributos e comportamentos em cada classe, protegendo 
dados e evitando alterações indevidas, como no status das tarefas. Já os relacionamentos 
entre classes, aliados à cardinalidade, ajudaram a definir de forma coerente como um 
usuário se liga às disciplinas, como as disciplinas se relacionam com tarefas e como o 
progresso pode ser acompanhado. 
 
Como proposta de solução, foi elaborado um modelo orientado a objetos com classes 
centrais diretamente relacionadas às funcionalidades descritas no desafio. A classe 
Usuário reúne dados de identificação e autenticação; Disciplina organiza as tarefas de 
estudo; Tarefa representa as atividades com atributos como título, descrição, prazo, 
prioridade e status; e Progresso registra a evolução do estudante em relação às atividades. 
Essa estrutura distribui melhor as responsabilidades e evita a concentração excessiva de 
funções em uma única classe. 
 
Além disso, os relacionamentos foram definidos de acordo com o comportamento 
esperado do sistema: um usuário pode possuir várias disciplinas, uma disciplina pode 
conter várias tarefas e cada tarefa pode apresentar registros de progresso. A 
representação desse modelo em um Diagrama de Classes UML tornou a solução mais 
clara e padronizada. A proposta também é sustentada pelos princípios de coesão, baixo 
acoplamento e encapsulamento, pois reduz ambiguidades, melhora a organização do 
código e favorece a manutenção futura do sistema. 
 
A elaboração deste memorial mostrou, na prática, que a modelagem orientada a objetos é 
decisiva para a qualidade de um projeto de software. Ao aplicar os conceitos da disciplina 
em uma situação concreta, ficou mais evidente que cada decisão de modelagem interfere 
diretamente na organização e na consistência do sistema. Com isso, foi possível 
compreender que projetar corretamente desde o início reduz retrabalho e torna o 
desenvolvimento mais seguro. 
 
Também percebi que a UML e as boas práticas de projeto não servem apenas para 
representar a estrutura do sistema, mas para melhorar a comunicação técnica e apoiar 
decisões mais consistentes. Essa experiência reforçou que a orientação a objetos é uma 
 
ferramenta essencial para transformar requisitos em soluções organizadas, 
compreensíveis e sustentáveis. 
 
Referências 
 
RANDO, D. R.; FREITAS, J. A.; POSSAMAI, J. C.; GUIMARÃES, L. V.; ALÉSSIO, S. C. Projeto 
Orientado a Objetos. Livro digital da disciplina. 
 
FIAP. Programação Orientada a Objetos: um guia completo sobre seus quatro pilares 
fundamentais. 
 
TECGRAF/PUC-Rio. Modelagem Orientada a Objetos. 
 
Autoavaliação 
 
Ao desenvolver esta atividade, percebi que meu aprendizado se torna mais sólido quando 
consigo relacionar teoria e prática de forma estruturada. Mais do que repetir conceitos, 
precisei interpretar o problema, selecionar os elementos mais relevantes e justificar cada 
escolha de modelagem. Isso tornou meu estudo mais crítico, mais ativo e mais próximo da 
realidade profissional.