Ciclos de vida, eventos e invariantes

1. Definir o objeto e a informação que o acompanha

Uma equipa está a especificar o tratamento de instruções de um serviço fictício. Para cada instrução, é necessário saber se ainda pode ser alterada, validada, comprometida ou cancelada. Começa por fixar a unidade de análise: uma instrução, com identidade estável durante toda a sequência.

Desenhar as tarefas de várias equipas pode ajudar a compreender o processo; para decidir o que uma instrução permite em cada momento, precisamos também do seu estado. Neste exercício, o estado completo contém phase, revision, validatedRevision e commitments.

A fase pode ser draft, open, committed ou cancelled. A revisão indica a versão do conteúdo; validatedRevision guarda a versão cuja validação foi concluída. A lista commitments regista os compromissos emitidos pelo modelo.

A instrução nasce em draft, revisão 1, sem validação e sem compromissos. A criação fica fora da sequência de eventos. Todos os eventos seguintes pertencem à mesma instrução.

Estas escolhas tornam o problema delimitado: o laboratório não resolve identidade de clientes, direitos de utilizadores, transporte de mensagens ou persistência. Ao rever um modelo de negócio, regista estas fronteiras junto do desenho. Um diagrama visualmente simples pode precisar de vários dados para permitir uma decisão correta.

2. Escrever evento, condição e efeito separadamente

Cada regra precisa de uma origem, um evento reconhecido, uma condição e um efeito definido. No contrato fictício, submit em draft abre a instrução. Em open, validate regista validatedRevision igual à revisão atual.

Este evento representa uma confirmação já concluída; o pedido de validação e o tempo para o executar não estão modelados. Ainda em open, amend aumenta a revisão de 1 para 2 e conserva a evidência da validação anterior. commit é permitido em open apenas quando validatedRevision e revision são iguais.

Nesse momento, muda a fase para committed e acrescenta um registo à lista de compromissos. cancel em open termina a instrução em cancelled. Um segundo commit em committed devolve already-committed e conserva todos os dados. Qualquer evento conhecido fora destas condições devolve not-permitted, sem mudar o estado.

Assim, a resposta de uma ação e a fase resultante são conceitos separados. Uma tentativa não permitida não cria automaticamente uma fase rejected. Quando o stakeholder usa palavras como aprovado ou processado, pede uma definição observável: que evidência existe, a que versão se refere, que alteração ocorreu e que ações passam a ser permitidas?

3. Conservar a memória necessária à decisão

Compara duas sequências a partir do estado inicial. A primeira é submit, validate, amend. Termina em open, revisão 2, com validatedRevision igual a 1.

A segunda é submit, amend, validate. Termina também em open e revisão 2, mas validatedRevision é 2. Um ecrã que apresente apenas open mostra o mesmo rótulo nos dois casos.

O próximo commit só está autorizado pelo modelo no segundo caso. Esta diferença demonstra por que a fase, isoladamente, não chega. Há duas formas possíveis de representar a distinção: acrescentar estados suficientemente precisos ou manter dados com condições explícitas.

O laboratório usa a segunda. Conservar a validação da revisão 1 permite explicar o histórico, sem a converter numa validação da revisão 2. Evita um campo booleano que continue a dizer validado depois de qualquer alteração, a menos que exista uma regra adicional que o torne inequívoco.

Nesta oficina só existe uma alteração possível. O limite de revisão 2 serve para tornar a exploração finita; uma aplicação real precisa de uma decisão própria sobre alterações adicionais. Não derives esse limite de uma recomendação de análise de negócio.

4. Comparar ordens e tratar o fim do ciclo

A ordem dos eventos faz parte do requisito. Na sequência submit, cancel, validate, commit, o cancelamento ocorre antes de existir compromisso. As duas ações seguintes devolvem not-permitted e a instrução fica cancelled, sem compromissos.

Na sequência submit, validate, commit, cancel, o compromisso já existe quando chega cancel. O cancelamento não é permitido e a instrução permanece committed, com um compromisso. Não há uma regra de estorno neste contrato.

Se o negócio precisar de desfazer um compromisso, é necessário especificar esse comportamento, incluindo efeitos e responsabilidades. Acrescentar uma seta de committed para cancelled não define o que acontece ao compromisso anterior. Para estudar a ordem, escreve o estado completo depois de cada evento e identifica a primeira diferença relevante.

Uma tentativa inválida intermédia pode conservar o estado e permitir que uma ação posterior válida tenha sucesso. Por exemplo, submit, commit, validate, commit termina com um compromisso: o primeiro commit falha por falta de validação; validate fornece a evidência; o segundo commit aplica a regra.

Estes são eventos serializados. A comparação não demonstra o comportamento de duas operações simultâneas num sistema distribuído.

5. Procurar sobreposições e lacunas nas condições

Considera agora uma pequena tabela separada do laboratório executável. Uma instrução aberta recebe route, com um montante inteiro entre 0 e 12 000 euros. A política fictícia exige revisão até 10 000 euros inclusive e escalonamento acima desse valor.

A primeira linha proposta diz montante <= 10 000, destino review; a segunda diz montante >= 10 000, destino escalate. Em 10 000, as duas linhas aplicam-se. Se a tabela não define prioridade, não há um destino único.

A correção que conserva a política é tornar a segunda condição estritamente maior que 10 000. Se ambas as condições fossem estritas, o valor 10 000 ficaria sem linha aplicável. Usa valores nas fronteiras e dentro de cada intervalo para distinguir sobreposição de lacuna.

Também verifica a possibilidade de chegar à origem de cada linha. Uma transição pode ter uma condição satisfazível e partir de uma fase que nunca é atingida desde o estado inicial. Uma tabela com uma resposta para cada montante ainda pode encaminhar todos para o destino de negócio errado.

Por isso, a revisão estrutural e a confirmação da intenção pelos responsáveis fornecem evidências diferentes. Estas condições numéricas pertencem apenas a este exemplo didático.

6. Verificar invariantes sobre os efeitos

O contrato estabelece três condições a preservar: cada instrução emite no máximo um compromisso; cada compromisso usa validação da revisão que compromete; uma instrução cancelled não tem compromissos. A lista de efeitos é necessária para verificar estas condições.

Uma variante defeituosa repete o efeito sempre que recebe commit em committed. A fase final continua committed após duas chamadas, mas a lista passa a ter dois registos. Um teste que confirme apenas o rótulo final não encontra esse erro.

Outra variante aceita qualquer validação anterior quando a instrução está open. Após submit, validate, amend, commit, emite um compromisso da revisão 2 usando validação da revisão 1. Registar o par no efeito torna o problema demonstrável.

Cada variante altera uma única regra para permitir uma comparação controlada. Preservar invariantes também não significa que o serviço progrida: um modelo que bloqueie todos os commits pode nunca duplicar um compromisso e falhar a necessidade de processar instruções válidas.

Acrescenta exemplos de progresso permitido aos exemplos de proibição. Estes invariantes são acordos fictícios explícitos; não se apresentam como política universal de pagamentos ou de certificação.

7. Explorar o modelo e interpretar a evidência

O material da aula permite alterar sequências e comparar o contrato de base com as duas variantes. Antes de executar, calcula à mão um traço curto e escreve os resultados esperados: estado inicial, evento, resposta, estado seguinte e compromissos acumulados.

O exemplo submit, validate, amend, commit exige quatro passos e termina sem compromisso na política de base. A variante de validação antiga fornece um contraexemplo ao invariante da revisão. Para a duplicação, usa submit, validate, commit, commit e conta os efeitos.

Quando o explorador enumera sequências, o universo fica definido pelo alfabeto de cinco eventos e pela profundidade escolhida. Uma pesquisa até quatro eventos não autoriza conclusões sobre todas as sequências mais longas. A oficina admite profundidades até seis e mantém revisões 1 e 2.

Compara a cobertura declarada com as regras que mudaste; um novo evento ou uma revisão adicional altera o universo. Um resultado de execução mostra o comportamento desse modelo e desses dados. Não demonstra entrega de mensagens, concorrência, transações, autorizações ou recuperação de um serviço real.

As instruções e resoluções descarregáveis explicam como repetir as experiências e interpretar cada resultado.

8. Transformar o modelo numa revisão útil

Leva à revisão um conjunto pequeno de traços que distinga decisões: validação atual seguida de compromisso, alteração posterior à validação, compromisso repetido e cancelamento antes ou depois do compromisso. Para cada traço, apresenta a regra aplicada e a evidência esperada, incluindo os efeitos.

Pede aos responsáveis que confirmem os resultados e os limites: quem reconhece a validação concluída, que alterações a invalidam, que compromissos têm significado de negócio e que recuperação precisa de um ciclo próprio? Uma tabela sem contradições pode representar mal essas necessidades.

Regista uma divergência como questão aberta com proprietário e impacto, antes de escolher silenciosamente uma interpretação. Se o sistema atual guarda apenas phase, identifica a informação adicional necessária para distinguir os dois estados open da aula.

Se a operação pede reversão, especifica um novo comportamento com critérios próprios. Para fechar a revisão, associa exemplos aceites às regras e aos pressupostos que sustentam. Uma mudança nesses pressupostos deve tornar visível o conjunto de exemplos a reconsiderar.

O artefacto final deve permitir que negócio, desenvolvimento, testes e suporte expliquem a mesma decisão usando o mesmo contexto.

Verificar segurança e progresso separadamente

Uma máquina de estados pode evitar efeitos duplicados e continuar a repetir para sempre. Considera uma automação fictícia que permite três tentativas por pedido lógico: sucesso conclui com um efeito; três falhas encaminham para revisão manual sem efeitos.

Cada tentativa responde em dez segundos no máximo e não existem outras esperas. O contador pertence ao pedido, não à visita a uma fase. Se entrar em pronto repõe o contador, o ciclo pronto, falha, repetir, pronto pode continuar indefinidamente.

Visitar todas as transições ou obter respostas determinísticas não elimina esse caminho. Para rever o requisito, segue três falhas consecutivas e verifica se chega à revisão manual; segue também sucesso na primeira, segunda e terceira tentativas.

O número de tentativas restantes diminui em cada tentativa, sem ser reposto nas mudanças de fase. Essa medida ajuda a justificar terminação nesta automação limitada. O limite temporal de trinta segundos depende das respostas e transições explicitamente descritas; não se transfere para chamadas externas sem prazo ou filas que o modelo omitiu.

Revisão manual termina a automação, mas não significa que o trabalho humano esteja concluído. No documento de requisitos, distingue efeito autorizado, resposta ao utilizador, terminação automática e responsabilidade pela continuação manual.

Armadilhas comuns

Guardar apenas o nome da fase; tratar uma tentativa não permitida como nova fase sem regra; conservar um booleano de validação após alteração; verificar o estado final sem contar efeitos; acrescentar cancelamento sem definir o destino de um compromisso anterior; apresentar enumeração limitada como prova de um sistema real.