2
respostas

BYTEBANK- DUVIDA DE LOGICA

Eu acredito que esse código está certo porque ele pega a ideia dos estados e transforma em etapas organizadas. Ele também usa criptografia e a verificação dos dados, que eram partes importantes do trabalho. Assim, os dados ficam protegidos durante o envio e não ficam expostos. Pelo que foi pedido, esse modelo atende os requisitos de segurança e faz o processo funcionar da forma correta. Peço aos instrutores confirmar se a logica fez sentido. Obrigada

INÍCIO

estado ← "ORIGEM"

ENQUANTO estado ≠ "FINALIZADO" FAÇA

    SE estado = "ORIGEM" ENTÃO
        
        // Processamento inicial
        dados ← coletarDados()

        // Segurança
        dadosCriptografados ← criptografar(dados)
        hashIntegridade ← gerarHash(dadosCriptografados)

        // Próximo estado
        estado ← "TRÂNSITO"

    FIMSE


    SE estado = "TRÂNSITO" ENTÃO

        // Dados trafegam protegidos
        transmitir(dadosCriptografados, hashIntegridade)

        // Mantém criptografia ativa
        estado ← "RECEPÇÃO"

    FIMSE


    SE estado = "RECEPÇÃO" ENTÃO

        // Validação de segurança
        hashRecebido ← gerarHash(dadosCriptografados)

        SE hashRecebido = hashIntegridade ENTÃO

            dadosFinais ← descriptografar(dadosCriptografados)

            ESCREVA "Transferência segura concluída"

        SENÃO

            ESCREVA "Falha: dados alterados"

        FIMSE

        estado ← "FINALIZADO"

    FIMSE

FIMENQUANTO

FIM

https://bytebank1.netlify.app/

Insira aqui a descrição dessa imagem para ajudar na acessibilidade https://bytebank1.netlify.app/

2 respostas

Olá, Lavinia! Como vai?

Que projeto incrível! Você pegou um desafio com contexto interessante, mas simples, e o transformou em uma solução lúdica e bem estruturada para o processo de segurança. Fico feliz em ver esse tipo de raciocínio sendo aplicado na prática.

Sua lógica faz sentido e está coerente com os requisitos propostos. Você organizou o fluxo em estados bem definidos, partindo da origem, passando pelo trânsito e chegando à recepção até o estado finalizado. Cada etapa cuida de uma responsabilidade específica: os dados ficam protegidos desde a coleta, a criptografia é aplicada antes do envio, e o hashIntegridade garante que nenhuma alteração ocorreu durante o caminho. A validação com gerarHash na recepção, comparando o hashRecebido com o hashIntegridade original, é exatamente o tipo de verificação que garante segurança real no processo.

Vale destacar também o uso correto das estruturas de controle, como o fimSe e o escreva, para exibir os resultados. Isso mostra atenção aos detalhes da lógica.

Uma dica para evoluir ainda mais: considere usar estruturas do tipo "SENÃO SE" em vez de vários blocos SE separados para os estados. Dessa forma, o fluxo fica mais eficiente e evita verificações desnecessárias a cada iteração. Testar cenários de erro, como dados corrompidos durante o trânsito, também é uma ótima forma de validar a robustez da sua solução.

Você está no caminho certo, Lavinia. Continue praticando esse tipo de modelagem com estados e segurança de dados.

Alura Conte com o apoio da comunidade Alura na sua jornada. Abraços e bons estudos!

Agora fica a pergunta: o que você acha que aconteceria se o hashRecebido fosse diferente do hashIntegridade em mais de uma tentativa seguida? Como você trataria esse cenário no seu algoritmo?

Oiii,
Não acredito que não coloquei a parte mais importante no algoritmo kkkk. (É que faço os algoritmos num papel, e depois peço pro Claude refazer certinho pra eu colar aqui. Foi falta de atenção minha na hora. )
Respondendo sua pergunta, eu preciso add um bloco de falhas, e caso tentasse mais de 3 vezes, aconteceria um bloqueio de segurança , e acredito que emitir um alerta tbm é essecial.