DEV Community

Cover image for Trajectory-Driven Development (T-DD): Desenvolvimento orientado por trajetórias semânticas de comportamento
suissAI
suissAI

Posted on

Trajectory-Driven Development (T-DD): Desenvolvimento orientado por trajetórias semânticas de comportamento

#architecture #software #allascode #tdd

Intent defines the starting semantic.
Trajectory defines the behavioral evolution.
Destination defines the expected terminal state.

Trajectory-Driven Development (T-DD) é uma proposta de método de desenvolvimento de software no qual a unidade central de especificação deixa de ser exclusivamente o código, o teste, a API, o requisito isolado ou o estado final do sistema e passa a ser a trajetória comportamental que conduz uma intenção a um destino verificável.

A implementação é tratada como uma projeção técnica dessa especificação.

O repositório que atualmente contém a implementação experimental deste conceito ainda utiliza o nome histórico Intent-Trajectory-Driven-Development. A documentação atual já apresenta a formulação Trajectory-Driven Development (T-DD) e a cadeia:

DESTINY
  ↓
INTENT
  ↓
BEHAVIOR
  ↓
EVIDENCE
  ↓
CONTRACT
  ↓
STATE
  ↓
ACTOR
  ↓
SKILL
  ↓
TRAJECTORY
  ↓
DSL
  ↓
IMPLEMENTATION
Enter fullscreen mode Exit fullscreen mode

Fonte canônica atual: suissa/Intent-Trajectory-Driven-Development

O objetivo deste documento é formalizar semanticamente essa proposta, relacioná-la às disciplinas existentes e estabelecer quais partes constituem síntese de conhecimentos existentes e quais partes constituem a contribuição específica do T-DD.

1. O problema que o T-DD tenta resolver

Grande parte das práticas tradicionais de desenvolvimento começa em algum artefato técnico intermediário:

API
 ↓
schema
 ↓
database
 ↓
route
 ↓
service
 ↓
UI
 ↓
test
Enter fullscreen mode Exit fullscreen mode

ou:

requirement
 ↓
implementation
 ↓
test
Enter fullscreen mode Exit fullscreen mode

ou ainda:

user story
 ↓
BDD scenario
 ↓
implementation
 ↓
acceptance test
Enter fullscreen mode Exit fullscreen mode

Essas abordagens são extremamente úteis, mas existe uma questão anterior:

Qual é exatamente o comportamento que estamos tentando realizar, por qual trajetória, sob quais condições, com quais atores, produzindo quais evidências e chegando a qual estado terminal?

Essa pergunta torna-se particularmente importante em sistemas:

  • distribuídos;
  • orientados a eventos;
  • conversacionais;
  • multiagente;
  • autônomos;
  • reativos;
  • baseados em workflows;
  • que possuem múltiplos atores;
  • que precisam explicar decisões;
  • que precisam reconstruir historicamente o comportamento;
  • ou nos quais o estado final não é suficiente para determinar se o comportamento foi correto.

O T-DD propõe que a especificação seja construída progressivamente até que a implementação possa ser considerada uma projeção verificável da trajetória declarada.

2. O que é e o que não é T-DD

T-DD não é simplesmente:

  • TDD com outro nome;
  • BDD;
  • workflow engine;
  • state machine;
  • process mining;
  • event sourcing;
  • requirements engineering;
  • model-driven development;
  • formal verification;
  • agent orchestration.

Ele utiliza ideias dessas áreas e procura integrá-las em torno de uma abstração comum:

trajetória semântica
Enter fullscreen mode Exit fullscreen mode

A distinção fundamental é:

TDD tradicional:
teste → implementação → refatoração

BDD:
comportamento → cenário → implementação → verificação

T-DD:
destino → intenção → comportamento → evidência
       → contrato → estado → autoridade → capacidade
       → trajetória → implementação → observação
       → comparação → conformidade
Enter fullscreen mode Exit fullscreen mode

O teste continua existindo.

O contrato continua existindo.

A máquina de estados continua existindo.

Os eventos continuam existindo.

A diferença é que eles deixam de ser artefatos independentes e passam a ser diferentes projeções da mesma especificação semântica.

3. Definição semântica

Uma definição compacta pode ser dada por:

T-DD := Development(Declaration, Refinement, Execution, Observation, Conformance)
Enter fullscreen mode Exit fullscreen mode

onde:

Declaration
    = especificação semântica desejada

Refinement
    = aumento monotônico de especificidade

Execution
    = realização da especificação

Observation
    = evidência produzida pela execução

Conformance
    = relação entre trajetória declarada e trajetória observada
Enter fullscreen mode Exit fullscreen mode

Uma especificação T-DD pode ser representada como:

Σ = ⟨D, I, B, E, C, S, A, K, T, X⟩
Enter fullscreen mode Exit fullscreen mode

onde:

Símbolo Conceito Significado
D Destiny estado/destino de negócio desejado
I Intent intenção semântica
B Behavior comportamento necessário
E Evidence evidência observável
C Contract restrições e invariantes
S State estados e transições legais
A Actor atores e autoridade
K Skill capacidades executáveis
T Trajectory sequência temporal de realização
X Exclusion comportamentos proibidos

A implementação:

P
Enter fullscreen mode Exit fullscreen mode

é considerada conforme quando:

P ⊨ T
Enter fullscreen mode Exit fullscreen mode

e a trajetória satisfaz as relações de refinamento:

T ⊨ B
B ⊨ I
I ⊨ D
Enter fullscreen mode Exit fullscreen mode

Portanto:

P ⊨ T ⊨ B ⊨ I ⊨ D
Enter fullscreen mode Exit fullscreen mode

Essa expressão é uma das formulações centrais do T-DD.

Ela não significa que uma intenção humana possa ser matematicamente provada em sua totalidade. Significa que, depois de semanticamente operacionalizada, cada camada deve satisfazer as restrições declaradas pela camada anterior.

4. A distinção entre Destiny, Intent e Trajectory

Uma das razões para separar esses conceitos é que eles respondem a perguntas diferentes.

Destiny

Responde:

Onde precisamos chegar?

Exemplo:

cliente solicita entrega
→ entrega executada
→ motoboy remunerado
Enter fullscreen mode Exit fullscreen mode

Formalmente:

D = {requested, paid, assigned, tracked, delivered, settled}
Enter fullscreen mode Exit fullscreen mode

O destino não é necessariamente uma única variável de estado. Ele pode ser uma conjunção de condições terminais.

Intent

Responde:

O que alguém está tentando realizar?

Exemplo:

customer wants delivery
Enter fullscreen mode Exit fullscreen mode

ou:

customer → deliver package from A to B
Enter fullscreen mode Exit fullscreen mode

A teoria do comportamento planejado de Ajzen fornece uma fundamentação importante para separar intenção de comportamento: intenções são antecedentes importantes do comportamento, embora não sejam equivalentes ao comportamento realizado. A literatura também enfatiza o papel do controle percebido e de outros fatores na passagem da intenção para a ação.

O T-DD aproveita essa distinção, mas a transforma em uma questão de engenharia:

Intent ≠ Behavior
Enter fullscreen mode Exit fullscreen mode

Uma intenção pode ser:

"quero fazer uma entrega"
Enter fullscreen mode Exit fullscreen mode

sem conter:

origem
destino
preço
pagamento
motoboy
código de entrega
Enter fullscreen mode Exit fullscreen mode

Portanto:

intent valid
≠
execution ready
Enter fullscreen mode Exit fullscreen mode

Essa distinção é essencial em sistemas conversacionais.

Trajectory

Responde:

Como a intenção se transforma em comportamento observável ao longo do tempo?

Exemplo:

Intent
  ↓
collect addresses
  ↓
discover couriers
  ↓
select courier
  ↓
request payment
  ↓
confirm payment
  ↓
release delivery
  ↓
track
  ↓
validate delivery
  ↓
settle courier
Enter fullscreen mode Exit fullscreen mode

Portanto:

Intent = semantic starting point

Destination = desired terminal condition

Trajectory = evolution between them
Enter fullscreen mode Exit fullscreen mode

5. Trajetória como objeto matemático

Em sistemas dinâmicos, uma trajetória pode ser entendida como a evolução de um estado ao longo de um domínio temporal.

Uma abstração simples:

τ : T → S
Enter fullscreen mode Exit fullscreen mode

onde:

T = domínio temporal
S = espaço de estados
τ(t) = estado observado no instante t
Enter fullscreen mode Exit fullscreen mode

Para software, podemos enriquecer essa definição:

τ = ⟨(s₀,a₀,e₀,t₀),
     (s₁,a₁,e₁,t₁),
     ...
     (sₙ,aₙ,eₙ,tₙ)⟩
Enter fullscreen mode Exit fullscreen mode

onde:

s = estado
a = ação
e = evidência
t = tempo
Enter fullscreen mode Exit fullscreen mode

Uma trajetória deixa então de ser simplesmente:

A → B → C
Enter fullscreen mode Exit fullscreen mode

e passa a ser:

(state, actor, action, evidence, time)
Enter fullscreen mode Exit fullscreen mode

Essa estrutura é muito mais próxima daquilo que sistemas distribuídos realmente precisam registrar.

6. Relação com máquinas de estados

O componente State do T-DD possui relação direta com máquinas de estados e, particularmente, com Statecharts.

Harel mostrou que statecharts podem representar sistemas discretos complexos incorporando hierarquia, concorrência e comunicação, tornando a especificação comportamental mais compacta e expressiva.

Um modelo T-DD pode ser:

STATE delivery {
    requested
    collecting
    searching
    assigned
    awaiting_payment
    paid
    active
    arriving
    delivered
    settled
    failed
}
Enter fullscreen mode Exit fullscreen mode

E:

FLOW delivery {
    requested → collecting
    collecting → searching
    searching → assigned
    assigned → awaiting_payment
    awaiting_payment → paid
    paid → active
    active → arriving
    arriving → delivered
    delivered → settled
}
Enter fullscreen mode Exit fullscreen mode

Isso permite expressar:

awaiting_payment → paid
Enter fullscreen mode Exit fullscreen mode

somente quando:

payment.confirmed = true
Enter fullscreen mode Exit fullscreen mode

O T-DD, portanto, não substitui máquinas de estados.

Ele as incorpora como uma dimensão da trajetória.

7. Relação com lógica temporal

Uma trajetória introduz naturalmente uma dimensão temporal.

Considere:

payment.requested
Enter fullscreen mode Exit fullscreen mode

e:

payment.confirmed
Enter fullscreen mode Exit fullscreen mode

Não basta que ambos sejam verdadeiros.

Precisamos estabelecer:

payment.requested
    precedes
payment.confirmed
Enter fullscreen mode Exit fullscreen mode

E:

delivery.released
Enter fullscreen mode Exit fullscreen mode

não pode ocorrer antes de:

payment.confirmed
Enter fullscreen mode Exit fullscreen mode

Essas relações são próximas da lógica temporal.

A lógica temporal linear e model checking fornecem métodos formais para verificar propriedades sobre sequências de estados e computações. Trabalhos de Pnueli, Clarke, Emerson e Sifakis estabeleceram bases fundamentais dessa área.

O T-DD pode, portanto, transformar:

X: ¬release(payment≠confirmed)
Enter fullscreen mode Exit fullscreen mode

em uma propriedade temporal verificável.

Por exemplo, conceitualmente:

G(release → previously(payment_confirmed))
Enter fullscreen mode Exit fullscreen mode

onde G pode representar uma propriedade que deve ser verdadeira globalmente ao longo da trajetória.

A implementação futura de um verificador T-DD pode transformar essas propriedades em fórmulas temporais formais.

8. Relação com lógica de Hoare

A lógica de Hoare introduziu uma maneira formal de raciocinar sobre propriedades de programas utilizando pré-condições, comandos e pós-condições. O trabalho seminal de Hoare de 1969 estabeleceu essa base axiomática para raciocinar sobre a corretude de programas.

Uma operação T-DD:

SKILL confirm_payment {
    in: payment
    inv: payment.valid
    out: payment.confirmed
}
Enter fullscreen mode Exit fullscreen mode

pode ser aproximada conceitualmente por:

{ payment.valid }
confirm_payment()
{ payment.confirmed }
Enter fullscreen mode Exit fullscreen mode

Mas T-DD adiciona dimensões que uma tripla de Hoare tradicional não representa diretamente:

actor
evidence
trajectory position
temporal relation
business destiny
semantic intent
Enter fullscreen mode Exit fullscreen mode

Assim:

Hoare Logic
    ↓
correctness of program state transformation

T-DD
    ↓
correctness of semantic trajectory
Enter fullscreen mode Exit fullscreen mode

A lógica de Hoare pode ser um mecanismo de verificação de partes do T-DD.

9. Relação com Design by Contract

O componente Contract possui relação direta com Design by Contract.

Meyer formalizou Design by Contract como uma abordagem para construção confiável de software utilizando contratos e asserções para explicitar condições de funcionamento.

Um contrato T-DD pode ser:

CONTRACT delivery.complete {
    in: code, location

    inv:
        code = valid
        ∧ location = dropoff
}
Enter fullscreen mode Exit fullscreen mode

Isso define:

preconditions
postconditions
invariants
failure conditions
Enter fullscreen mode Exit fullscreen mode

A diferença está no nível de integração.

No T-DD:

Contract
Enter fullscreen mode Exit fullscreen mode

não é um artefato isolado.

Ele pertence à trajetória:

Intent
 ↓
Behavior
 ↓
Contract
 ↓
State
 ↓
Trajectory
Enter fullscreen mode Exit fullscreen mode

Consequentemente, um contrato pode ser utilizado por:

  • runtime;
  • agente;
  • gerador de código;
  • gerador de testes;
  • observabilidade;
  • verificador;
  • simulador;
  • process miner.

10. Relação com Requirements Engineering

Requirements Engineering tradicionalmente procura capturar aquilo que o sistema deve realizar e preservar a relação entre requisitos e artefatos técnicos.

O problema de traceability é antigo e bem documentado. Gotel e Finkelstein demonstraram que a rastreabilidade de requisitos envolve tanto o período anterior à especificação quanto o posterior à especificação, e que problemas importantes surgem quando a rastreabilidade inicial é perdida.

O T-DD pode ser interpretado como uma tentativa de tornar essa rastreabilidade estrutural:

DESTINY
   ↕
INTENT
   ↕
BEHAVIOR
   ↕
EVIDENCE
   ↕
CONTRACT
   ↕
STATE
   ↕
ACTOR
   ↕
SKILL
   ↕
TRAJECTORY
   ↕
IMPLEMENTATION
Enter fullscreen mode Exit fullscreen mode

Assim, em vez de uma matriz externa:

Requirement → Design → Code → Test
Enter fullscreen mode Exit fullscreen mode

temos uma cadeia semântica na qual cada camada possui identidade própria.

Isso permite perguntar:

Qual código implementa esta Skill?
Enter fullscreen mode Exit fullscreen mode

ou:

Qual Skill realiza este Behavior?
Enter fullscreen mode Exit fullscreen mode

ou:

Qual Intent originou este Behavior?
Enter fullscreen mode Exit fullscreen mode

ou:

Qual Destiny depende desta Intent?
Enter fullscreen mode Exit fullscreen mode

ou:

Qual evidência prova que essa intenção foi realizada?
Enter fullscreen mode Exit fullscreen mode

Esse encadeamento é uma aplicação direta do princípio de traceability, mas elevado a uma estrutura semântica explícita.

11. Relação com Goal-Oriented Requirements Engineering

A literatura de Goal-Oriented Requirements Engineering trabalha há décadas com a ideia de derivar requisitos a partir de objetivos.

Van Lamsweerde, por exemplo, desenvolveu amplamente a abordagem goal-oriented para requirements engineering. Goal-oriented Requirements Engineering: a guided tour

O T-DD possui uma relação direta:

Goal
 ↓
Destiny
 ↓
Intent
 ↓
Behavior
Enter fullscreen mode Exit fullscreen mode

A diferença proposta está no tratamento da dimensão temporal.

Um goal pode ser:

deliver package
Enter fullscreen mode Exit fullscreen mode

O T-DD pergunta adicionalmente:

como esse objetivo será realizado?

quais estados intermediários existem?

quais atores podem produzir cada transição?

quais evidências comprovam cada passo?

quais trajetórias são permitidas?

quais trajetórias são proibidas?
Enter fullscreen mode Exit fullscreen mode

Isso aproxima T-DD de uma combinação entre:

Goal-oriented RE
+
State-based modeling
+
Process modeling
+
Trace semantics
+
Conformance checking
Enter fullscreen mode Exit fullscreen mode

12. Uma conexão particularmente importante: Intent Mining

Existe uma linha de pesquisa surpreendentemente próxima do conceito.

Pesquisas de intentional process mining procuram descobrir intenções e estratégias a partir de logs de processos.

Khodabandelou et al. apresentaram trabalhos sobre descoberta de modelos intencionais a partir de logs, inclusive utilizando Hidden Markov Models para inferir intenções e estratégias dos participantes. Unsupervised discovery of intentional process models from event logs

Outra revisão sistemática conecta explicitamente:

event logs
→ processes
→ goals
Enter fullscreen mode Exit fullscreen mode

e documenta a relação entre process mining, intention mining e goal-oriented requirements engineering. From event logs to goals: a systematic literature review of goal-oriented process mining

Isso é extremamente relevante para T-DD.

A direção tradicional do process mining é:

OBSERVED TRAJECTORIES
        ↓
PROCESS MODEL
Enter fullscreen mode Exit fullscreen mode

Enquanto T-DD propõe:

DECLARED TRAJECTORY
        ↓
IMPLEMENTATION
        ↓
OBSERVED TRAJECTORY
        ↓
CONFORMANCE
Enter fullscreen mode Exit fullscreen mode

Temos, portanto, duas operações complementares:

Process Mining:

events → infer model


T-DD:

model → expected events
Enter fullscreen mode Exit fullscreen mode

E futuramente:

T-DD + Process Mining

declared trajectory
        ↓
executed system
        ↓
observed trajectory
        ↓
alignment
        ↓
conformance / deviation / repair
Enter fullscreen mode Exit fullscreen mode

Esse é um dos fundamentos científicos mais fortes para o conceito.

13. Relação com Process Mining

Process mining trabalha na interseção entre:

process models
+
event data
Enter fullscreen mode Exit fullscreen mode

A literatura de van der Aalst estabelece três grandes atividades:

discovery
conformance
enhancement
Enter fullscreen mode Exit fullscreen mode

e utiliza event logs para descobrir ou analisar processos reais.

No T-DD:

DECLARED TRAJECTORY
Enter fullscreen mode Exit fullscreen mode

é um processo esperado.

O sistema produz:

OBSERVED TRAJECTORY
Enter fullscreen mode Exit fullscreen mode

A comparação:

expected ↔ observed
Enter fullscreen mode Exit fullscreen mode

é um problema de conformidade.

Van der Aalst e colaboradores estudaram justamente o replay de históricos sobre modelos de processos para análise de conformidade e desempenho. Replaying history on process models for conformance checking and performance analysis

Portanto, uma implementação futura do T-DD pode utilizar técnicas de process mining para responder:

A trajetória real corresponde à trajetória declarada?
Enter fullscreen mode Exit fullscreen mode

14. Relação com Event Sourcing

Event Sourcing registra mudanças de estado como uma sequência de eventos, permitindo reconstruir estados anteriores e responder não apenas "onde estamos", mas também "como chegamos aqui". Fowler descreve justamente essa diferença entre consultar o estado atual e preservar a sequência histórica das mudanças.

Isso é extremamente próximo da ideia de trajetória.

Porém:

Event Sourcing
    = mecanismo de persistência histórica

T-DD
    = método de especificação e desenvolvimento
Enter fullscreen mode Exit fullscreen mode

Event Sourcing pode fornecer a matéria-prima para:

ObservedTrajectory
Enter fullscreen mode Exit fullscreen mode

mas não define sozinho:

Intent
Destiny
Contract
Actor
Skill
ExpectedTrajectory
Enter fullscreen mode Exit fullscreen mode

Portanto:

T-DD
   +
Event Sourcing
   =
declared semantics + historical execution
Enter fullscreen mode Exit fullscreen mode

15. Estado atual não é trajetória

Essa distinção é fundamental.

Imagine dois sistemas que terminaram assim:

delivery.status = settled
Enter fullscreen mode Exit fullscreen mode

Ambos possuem o mesmo estado final.

Mas:

Trajetória A 

requested
→ assigned
→ paid
→ active
→ delivered
→ settled
Enter fullscreen mode Exit fullscreen mode

Trajetória B 

requested
→ assigned
→ settled
Enter fullscreen mode Exit fullscreen mode

O estado final é igual:

settled
Enter fullscreen mode Exit fullscreen mode

A semântica é completamente diferente.

O segundo sistema pode ter violado:

payment.confirmed
delivery.completed
delivery.code.validated
Enter fullscreen mode Exit fullscreen mode

Portanto:

State(t_final)
Enter fullscreen mode Exit fullscreen mode

não é suficiente para determinar:

CorrectTrajectory
Enter fullscreen mode Exit fullscreen mode

Essa é uma das razões centrais para tratar a trajetória como artefato de primeira classe.

16. Relação com Behavior-Driven Development

BDD aproxima negócio, desenvolvimento e testes por meio de comportamento executável.

A literatura sobre BDD descreve justamente a intenção de expressar comportamento de forma compreensível para diferentes participantes e associar comportamentos a cenários executáveis. Behaviour-Driven Development of Foundational UML Components

Um cenário BDD típico:

Given payment was confirmed
When delivery is released
Then courier receives delivery data
Enter fullscreen mode Exit fullscreen mode

T-DD pode representar isso como parte de uma trajetória maior:

payment.confirmed
    ↓
delivery.released
    ↓
courier.receives
Enter fullscreen mode Exit fullscreen mode

A diferença é de escopo.

BDD
→ comportamento esperado em cenários

T-DD
→ evolução temporal completa de uma intenção até seu destino
Enter fullscreen mode Exit fullscreen mode

BDD pode, portanto, ser uma projeção de uma trajetória T-DD:

Trajectory
   ↓
BDD Scenarios
Enter fullscreen mode Exit fullscreen mode

Assim como:

Trajectory
   ↓
Tests
Enter fullscreen mode Exit fullscreen mode

ou:

Trajectory
   ↓
State Machine
Enter fullscreen mode Exit fullscreen mode

17. Relação com Test-Driven Development

TDD tradicional começa com um teste que expressa uma mudança desejada, implementa-se código para satisfazê-lo e posteriormente refatora-se a implementação.

Esse ciclo é extremamente eficiente para orientar a construção local do software.

T-DD muda o objeto primário:

TDD:
test is primary artifact

T-DD:
trajectory is primary semantic artifact
Enter fullscreen mode Exit fullscreen mode

Um teste pode verificar:

assert payment.confirmed
Enter fullscreen mode Exit fullscreen mode

Mas uma trajetória verifica:

request
→ payment.requested
→ payment.confirmed
→ delivery.released
Enter fullscreen mode Exit fullscreen mode

E também:

¬delivery.released
before payment.confirmed
Enter fullscreen mode Exit fullscreen mode

Portanto:

TDD verifica comportamento local.

T-DD especifica e verifica evolução comportamental.
Enter fullscreen mode Exit fullscreen mode

Os dois podem coexistir:

T-DD
 ↓
gera/define
 ↓
TDD tests
Enter fullscreen mode Exit fullscreen mode

18. Relação com Model-Driven Development

Model-driven approaches utilizam modelos como artefatos fundamentais e frequentemente derivam artefatos técnicos desses modelos.

T-DD segue uma ideia semelhante:

semantic model
 ↓
DSL
 ↓
generated artifacts
 ↓
implementation
Enter fullscreen mode Exit fullscreen mode

Mas o objeto central não é simplesmente um modelo estrutural.

É uma trajetória:

semantic model
=
intent + behavior + state + actor + evidence + trajectory
Enter fullscreen mode Exit fullscreen mode

Isso aproxima T-DD de uma forma de trajectory-centered model-driven development.

A DSL torna-se uma representação compacta de um modelo semântico previamente definido.

19. A escada monotônica de especificidade

Uma propriedade importante do T-DD é a ideia de refinamento monotônico.

Definimos:

S₀ = Destiny
S₁ = Intent
S₂ = Behavior
...
Sₙ = Implementation
Enter fullscreen mode Exit fullscreen mode

com:

S₀ ⊆ S₁ ⊆ S₂ ⊆ ... ⊆ Sₙ
Enter fullscreen mode Exit fullscreen mode

O símbolo ⊆ aqui deve ser interpretado semanticamente:

cada estágio adiciona restrições sem invalidar o significado estabelecido anteriormente.

Por exemplo:

Destiny:
"entrega deve ser concluída"

Intent:
"cliente quer entregar pacote de A para B"

Behavior:
"buscar entregador e executar entrega"

Contract:
"pagamento precisa ser confirmado antes da liberação"

State:
"awaiting_payment → paid → active"

Actor:
"somente payment pode confirmar pagamento"

Skill:
"confirm_payment"

Trajectory:
"request → collect → select → pay → release → track → deliver"

Implementation:
"WhatsApp + PostgreSQL + NATS + provider X"
Enter fullscreen mode Exit fullscreen mode

A última camada possui muito mais informação técnica, mas não deveria alterar o significado das anteriores.

20. O princípio de separação semântica

O T-DD estabelece:

technology ≠ semantics
Enter fullscreen mode Exit fullscreen mode

Uma API:

POST /delivery
Enter fullscreen mode Exit fullscreen mode

não é o comportamento.

Uma tabela:

deliveries
Enter fullscreen mode Exit fullscreen mode

não é o comportamento.

Uma função:

createDelivery()
Enter fullscreen mode Exit fullscreen mode

não é o comportamento.

Um agente:

DeliveryAgent
Enter fullscreen mode Exit fullscreen mode

não é o comportamento.

Todos são implementações possíveis de uma semântica anterior.

Portanto:

semantic specification
        ↓
implementation projection
Enter fullscreen mode Exit fullscreen mode

e não:

implementation
        ↓
retroactive semantic interpretation
Enter fullscreen mode Exit fullscreen mode

Essa inversão é uma das características mais importantes da proposta.

21. Actor como autoridade semântica

O T-DD introduz explicitamente:

ACTOR
Enter fullscreen mode Exit fullscreen mode

porque comportamento não pode ser separado de autoridade.

Exemplo:

ACTOR customer
ACTOR courier
ACTOR payment
ACTOR system
Enter fullscreen mode Exit fullscreen mode

Então:

ALLOW customer {
    request
    address
    pay
}
Enter fullscreen mode Exit fullscreen mode

e:

ALLOW payment {
    confirm
    reject
}
Enter fullscreen mode Exit fullscreen mode

Isso permite distinguir:

technically executable
Enter fullscreen mode Exit fullscreen mode

de:

semantically authorized
Enter fullscreen mode Exit fullscreen mode

Uma função poder ser chamada pelo código não significa que o ator atual esteja autorizado a executá-la.

Essa separação é especialmente importante para:

  • agentes;
  • sistemas multiusuário;
  • sistemas distribuídos;
  • segurança;
  • compliance;
  • human-in-the-loop;
  • workflows empresariais.

22. Skill como unidade executável

A Skill representa uma capacidade semanticamente delimitada.

Exemplo:

SKILL select_nearest {
    in: couriers, origin

    rule:
        min(distance(courier, origin))

    out:
        courier

    emit:
        courier.selected
}
Enter fullscreen mode Exit fullscreen mode

Uma Skill possui:

input
output
rule
invariants
evidence
actor
Enter fullscreen mode Exit fullscreen mode

Ela pode então ser utilizada por:

agent
workflow
test
runtime
simulator
human
Enter fullscreen mode Exit fullscreen mode

Isso permite separar:

what can be done
Enter fullscreen mode Exit fullscreen mode

de:

who orchestrates it
Enter fullscreen mode Exit fullscreen mode

Uma Skill não precisa saber se foi chamada por:

LLM
HTTP
CLI
WhatsApp
workflow
human
Enter fullscreen mode Exit fullscreen mode

A semântica permanece a mesma.

23. Evidence como primeiro cidadão

Um dos pontos mais importantes do T-DD é colocar evidência antes da implementação.

Exemplo:

EVIDENCE delivery {
    request.received
    intent.recognized
    addresses.collected
    courier.selected
    payment.confirmed
    delivery.released
    location.received*
    code.validated
    settlement.completed
}
Enter fullscreen mode Exit fullscreen mode

Isso significa que observabilidade não é:

"vamos adicionar logs depois"
Enter fullscreen mode Exit fullscreen mode

mas:

"quais fatos precisam ser observáveis para provar que o comportamento ocorreu?"
Enter fullscreen mode Exit fullscreen mode

A diferença é arquitetural.

Um log:

"payment succeeded"
Enter fullscreen mode Exit fullscreen mode

não é necessariamente uma evidência confiável.

Uma evidência precisa estar vinculada a uma condição semântica verificável:

payment.confirmed
Enter fullscreen mode Exit fullscreen mode

e, idealmente:

actor
timestamp
correlation_id
state_before
action
state_after
provenance
Enter fullscreen mode Exit fullscreen mode

24. Proveniência

A evidência também pode possuir proveniência:

Evidence =
    ⟨fact, actor, timestamp, source, provenance⟩
Enter fullscreen mode Exit fullscreen mode

Por exemplo:

payment.confirmed
actor: payment-provider
timestamp: 2026-10-07T10:32:12Z
source: provider-event
Enter fullscreen mode Exit fullscreen mode

Isso permite diferenciar:

claim
Enter fullscreen mode Exit fullscreen mode

de:

observed fact
Enter fullscreen mode Exit fullscreen mode

Essa propriedade torna-se especialmente importante para sistemas de agentes.

Um agente pode dizer:

"o pagamento foi confirmado"
Enter fullscreen mode Exit fullscreen mode

mas o sistema deve conseguir responder:

qual evidência sustenta essa afirmação?
Enter fullscreen mode Exit fullscreen mode

25. T-DD e sistemas de agentes

O modelo torna-se especialmente interessante para agentes porque agentes frequentemente operam em loops:

observe
→ reason
→ act
→ observe
→ reason
→ act
Enter fullscreen mode Exit fullscreen mode

Um agente tradicional pode produzir uma sequência de chamadas de ferramentas sem possuir uma representação formal da trajetória.

T-DD propõe:

Intent
 ↓
Expected Trajectory
 ↓
Agent Actions
 ↓
Observed Evidence
 ↓
Trajectory Update
 ↓
Conformance
Enter fullscreen mode Exit fullscreen mode

O agente deixa de ser simplesmente:

LLM + tools
Enter fullscreen mode Exit fullscreen mode

e passa a ser um participante de uma trajetória semanticamente definida.

26. Agente não define a semântica

Essa distinção é essencial.

O agente pode escolher:

qual Skill executar
Enter fullscreen mode Exit fullscreen mode

mas não deveria poder alterar silenciosamente:

qual Destiny está sendo perseguido
Enter fullscreen mode Exit fullscreen mode

nem:

quais invariantes são obrigatórios
Enter fullscreen mode Exit fullscreen mode

Por exemplo:

X:
¬release(payment ≠ confirmed)
Enter fullscreen mode Exit fullscreen mode

O agente pode tentar várias estratégias para conseguir confirmação.

Mas não pode decidir:

"vou liberar mesmo sem pagamento"
Enter fullscreen mode Exit fullscreen mode

sem que a especificação permita essa transição.

Isso produz:

agent autonomy
within semantic boundaries
Enter fullscreen mode Exit fullscreen mode

e não:

agent autonomy
over system meaning
Enter fullscreen mode Exit fullscreen mode

27. Relação com sociologia: ação, intenção e trajetória

A palavra "ação" em sistemas de software possui uma herança conceitual muito maior do que simplesmente chamar uma função.

Em ciências sociais, uma ação pode ser estudada considerando:

ator
intenção
contexto
normas
recursos
ação
consequência
Enter fullscreen mode Exit fullscreen mode

O T-DD possui uma estrutura semelhante:

ACTOR
INTENT
CONTEXT
CONTRACT
ACTION
EVIDENCE
STATE
CONSEQUENCE
Enter fullscreen mode Exit fullscreen mode

Mas isso não significa que T-DD esteja propondo uma teoria sociológica nova.

A contribuição é transportar uma distinção útil para sistemas computacionais:

ação técnica
≠
ação semanticamente situada
Enter fullscreen mode Exit fullscreen mode

Em sistemas multiagente e conversacionais, isso se torna particularmente importante porque o mesmo comando técnico pode possuir significados diferentes dependendo do ator, contexto e estado.

28. Intenção não determina automaticamente ação

A literatura psicológica fornece um alerta importante.

A teoria do comportamento planejado de Ajzen mostra que intenção é um determinante importante, mas não suficiente para garantir comportamento; o controle percebido e outros fatores também importam.

Isso pode ser traduzido arquiteturalmente:

Intent
  ≠
Guaranteed Execution
Enter fullscreen mode Exit fullscreen mode

Uma intenção pode falhar porque:

missing information
authorization denied
resource unavailable
provider failure
state invalid
contract violation
actor unavailable
timeout
Enter fullscreen mode Exit fullscreen mode

Logo:

Intent
 ↓
possible trajectories
Enter fullscreen mode Exit fullscreen mode

e não:

Intent
 ↓
one guaranteed action
Enter fullscreen mode Exit fullscreen mode

Essa observação fundamenta a necessidade de representar falhas e replanejamento como partes legítimas da trajetória.

29. Trajetória pode ramificar

Uma trajetória real não precisa ser linear.

Podemos ter:

request
  ↓
payment
  ├── confirmed
  │     ↓
  │   release
  │
  └── rejected
        ↓
      retry
Enter fullscreen mode Exit fullscreen mode

Formalmente:

T = graph(S, A, E)
Enter fullscreen mode Exit fullscreen mode

em vez de simplesmente:

T = list(A)
Enter fullscreen mode Exit fullscreen mode

Portanto:

Trajectory
Enter fullscreen mode Exit fullscreen mode

pode ser:

  • linear;
  • ramificada;
  • concorrente;
  • iterativa;
  • recursiva;
  • parcialmente ordenada.

Isso aproxima T-DD de:

  • statecharts;
  • Petri nets;
  • process calculi;
  • workflow models;
  • temporal logic;
  • process mining.

30. Relação com Petri Nets

Petri nets são uma das bases formais mais importantes para modelagem de workflows.

Van der Aalst demonstrou sua aplicação à gestão de workflows, destacando tanto sua capacidade de especificação quanto as possibilidades de análise formal de procedimentos.

Uma trajetória T-DD pode eventualmente ser compilada para uma estrutura semelhante.

Por exemplo:

requested
    ↓
collecting
    ↓
searching
    ↓
assigned
Enter fullscreen mode Exit fullscreen mode

pode ser representada como uma rede.

A vantagem seria permitir analisar:

deadlocks
liveness
reachability
concurrency
soundness
Enter fullscreen mode Exit fullscreen mode

O T-DD não precisa substituir Petri nets.

Uma arquitetura possível é:

T-DD DSL
    ↓
semantic model
    ↓
Petri-net projection
    ↓
formal analysis
Enter fullscreen mode Exit fullscreen mode

Isso seria uma evolução natural da proposta.

31. Conformidade como relação formal

Definimos:

T_expected
Enter fullscreen mode Exit fullscreen mode

como a trajetória declarada.

E:

T_observed
Enter fullscreen mode Exit fullscreen mode

como a trajetória observada.

A conformidade pode ser representada por:

Conforms(T_observed, T_expected)
Enter fullscreen mode Exit fullscreen mode

Uma forma simples:

T_observed ⊨ T_expected
Enter fullscreen mode Exit fullscreen mode

Mas a relação real pode ser mais rica.

Podemos definir:

Conformance =
    structural
    ∧ temporal
    ∧ contractual
    ∧ authorization
    ∧ evidential
Enter fullscreen mode Exit fullscreen mode

Então:

Conformance(To, Te)
=
Cstructural
∧ Ctemporal
∧ Ccontract
∧ Cactor
∧ Cevidence
Enter fullscreen mode Exit fullscreen mode

Isso permite classificar desvios:

STRUCTURAL_DEVIATION
TEMPORAL_DEVIATION
CONTRACT_DEVIATION
AUTHORIZATION_DEVIATION
MISSING_EVIDENCE
UNEXPECTED_ACTION
INVALID_STATE_TRANSITION
Enter fullscreen mode Exit fullscreen mode

32. Trajectory Distance

Uma evolução matemática natural é definir uma distância entre trajetórias.

Por exemplo:

d(T_expected, T_observed)
Enter fullscreen mode Exit fullscreen mode

poderia considerar:

missing actions
extra actions
wrong ordering
wrong actor
wrong state
missing evidence
Enter fullscreen mode Exit fullscreen mode

Uma função simplificada:

d(Tₑ,Tₒ)
=
αM
+
βX
+
γO
+
δA
+
εS
+
ζE
Enter fullscreen mode Exit fullscreen mode

onde:

M = missing actions
X = unexpected actions
O = ordering deviations
A = actor deviations
S = state deviations
E = evidence deviations
Enter fullscreen mode Exit fullscreen mode

Os pesos:

α β γ δ ε ζ
Enter fullscreen mode Exit fullscreen mode

podem ser definidos conforme o domínio.

Isso abre espaço para:

trajectory similarity
trajectory clustering
trajectory anomaly detection
trajectory ranking
trajectory repair
Enter fullscreen mode Exit fullscreen mode

33. Conformance não precisa ser binária

Em sistemas complexos:

conforms = true/false
Enter fullscreen mode Exit fullscreen mode

pode ser insuficiente.

Podemos ter:

ConformanceScore ∈ [0,1]
Enter fullscreen mode Exit fullscreen mode

Por exemplo:

0.98
Enter fullscreen mode Exit fullscreen mode

pode significar que a trajetória possui pequena divergência não crítica.

Enquanto:

0.20
Enter fullscreen mode Exit fullscreen mode

pode indicar que o sistema praticamente abandonou a trajetória declarada.

Mas alguns invariantes devem ser absolutos:

payment confirmed before release
Enter fullscreen mode Exit fullscreen mode

não deveria ser transformado simplesmente em:

97% compliant
Enter fullscreen mode Exit fullscreen mode

Portanto, T-DD deve distinguir:

soft constraints
Enter fullscreen mode Exit fullscreen mode

de:

hard invariants
Enter fullscreen mode Exit fullscreen mode

34. Hard e Soft Semantics

Podemos definir:

C = Chard ∪ Csoft
Enter fullscreen mode Exit fullscreen mode

Exemplo:

HARD:
¬release(payment≠confirmed)

SOFT:
select courier with minimal distance
Enter fullscreen mode Exit fullscreen mode

Assim:

payment confirmation
Enter fullscreen mode Exit fullscreen mode

é obrigatório.

Enquanto:

nearest courier
Enter fullscreen mode Exit fullscreen mode

pode admitir:

second nearest
Enter fullscreen mode Exit fullscreen mode

quando o primeiro estiver indisponível.

Isso é particularmente importante para agentes.

O agente pode otimizar:

soft constraints
Enter fullscreen mode Exit fullscreen mode

mas não violar:

hard constraints
Enter fullscreen mode Exit fullscreen mode

35. Replanejamento

Quando uma trajetória falha, o sistema não precisa necessariamente declarar a intenção como impossível.

Exemplo:

Intent:
deliver package
Enter fullscreen mode Exit fullscreen mode

Primeira trajetória:

select courier A
→ courier rejects
Enter fullscreen mode Exit fullscreen mode

Uma segunda trajetória pode ser:

select courier B
→ accept
→ pay
→ release
Enter fullscreen mode Exit fullscreen mode

Portanto:

Intent
   ↓
Trajectory₁
   ↓
failure
   ↓
replanning
   ↓
Trajectory₂
   ↓
Destination
Enter fullscreen mode Exit fullscreen mode

A intenção permanece.

A trajetória muda.

Essa distinção é especialmente importante em sistemas agentes.

36. Intenção persistente, trajetória mutável

Uma formulação importante:

Intent = relatively stable semantic objective

Trajectory = mutable realization strategy
Enter fullscreen mode Exit fullscreen mode

Isso significa:

same intent
+
different trajectory
=
valid adaptation
Enter fullscreen mode Exit fullscreen mode

desde que:

trajectory ⊨ intent
Enter fullscreen mode Exit fullscreen mode

Essa propriedade permite que um agente faça planejamento adaptativo sem modificar arbitrariamente o objetivo semântico.

37. A relação com "Situated Action"

A pesquisa de interação humano-computador e ciências sociais também mostrou limitações de tratar ação humana como simples execução de planos predefinidos.

O trabalho de Lucy Suchman sobre Plans and Situated Actions tornou-se uma referência importante para compreender como ações são produzidas em situações concretas, em vez de simplesmente executar planos abstratos.

O paralelo para T-DD é:

declared trajectory
Enter fullscreen mode Exit fullscreen mode

não precisa significar:

fixed deterministic script
Enter fullscreen mode Exit fullscreen mode

Ela pode representar:

semantic constraints
Enter fullscreen mode Exit fullscreen mode

dentro das quais a execução pode adaptar-se ao contexto.

Isso sugere uma distinção:

Trajectory Specification
≠
Execution Script
Enter fullscreen mode Exit fullscreen mode

A primeira define:

what must remain true
Enter fullscreen mode Exit fullscreen mode

A segunda define:

how one execution currently proceeds
Enter fullscreen mode Exit fullscreen mode

Essa distinção é particularmente útil para agentes.

38. T-DD como "semantic constraint system"

Uma maneira mais precisa de definir T-DD é:

T-DD é um sistema de desenvolvimento no qual uma trajetória declarada funciona como uma estrutura de restrições semânticas progressivamente refinadas, contra a qual implementações e execuções podem ser verificadas.

Nesse sentido:

T-DD ≈ semantic constraint refinement
Enter fullscreen mode Exit fullscreen mode

e:

Implementation = realization
Execution = instantiation
Observation = evidence
Conformance = verification
Enter fullscreen mode Exit fullscreen mode

39. A DSL como compressão semântica

A DSL não deve ser o primeiro artefato.

Ela é o resultado da especificação.

Por exemplo:

DESTINY
INTENT
BEHAVIOR
CONTRACT
STATE
ACTOR
EVIDENCE
TRAJECTORY
Enter fullscreen mode Exit fullscreen mode

pode ser comprimido em:

@delivery

D: delivery→requested paid assigned tracked delivered settled

I: customer→deliver

B:
  request
  →collect
  →discover(courier*)
  →select(min distance)
  →charge
  →confirm
  →release
  →track*
  →validate(code)
  →settle

S:
  requested
  →collecting
  →searching
  →assigned
  →awaiting_payment
  →paid
  →active
  →arriving
  →delivered
  →settled

X:
  ¬release(payment≠confirmed)
  ¬settle(code≠valid)
Enter fullscreen mode Exit fullscreen mode

A DSL não inventa esses significados.

Ela os codifica.

Portanto:

Semantic Model
      ↓
DSL
Enter fullscreen mode Exit fullscreen mode

e não:

DSL
 ↓
invent semantic meaning
Enter fullscreen mode Exit fullscreen mode

40. Semantic Source of Truth

Uma propriedade desejável é:

DSL = semantic source of truth
Enter fullscreen mode Exit fullscreen mode

enquanto:

TypeScript
Python
Zig
SQL
OpenAPI
routes
schemas
tests
agent tools
Enter fullscreen mode Exit fullscreen mode

são projeções.

Por exemplo:

T-DD DSL
    ├──→ TypeScript
    ├──→ Python
    ├──→ OpenAPI
    ├──→ JSON Schema
    ├──→ tests
    ├──→ state machine
    ├──→ agent tools
    └──→ documentation
Enter fullscreen mode Exit fullscreen mode

Essa arquitetura aproxima T-DD de:

Model-Driven Engineering
+
Schema-Driven Development
+
Code Generation
Enter fullscreen mode Exit fullscreen mode

mas utiliza uma semântica centrada na trajetória.

41. Relação com Design Science Research

O T-DD também pode ser estudado como um artefato de Design Science Research.

A literatura de DSR caracteriza esse tipo de pesquisa pela construção e avaliação de artefatos, acompanhando a transformação de problemas em requisitos, artefatos e evidências de avaliação.

Isso é particularmente relevante para a evolução do T-DD porque permite separar:

claim
Enter fullscreen mode Exit fullscreen mode

de:

implementation
Enter fullscreen mode Exit fullscreen mode

e:

evidence
Enter fullscreen mode Exit fullscreen mode

A pesquisa do método pode então seguir:

Problem
 ↓
Concept
 ↓
Formalization
 ↓
DSL
 ↓
Implementation
 ↓
Execution
 ↓
Evaluation
 ↓
Conformance
 ↓
Revision
Enter fullscreen mode Exit fullscreen mode

Isso transforma o próprio desenvolvimento do T-DD em uma instância de T-DD.

42. Autoaplicação

Uma propriedade interessante da metodologia é que ela pode especificar a si mesma.

Exemplo:

DESTINY:
produce a system whose implementation conforms
to declared semantic trajectories
Enter fullscreen mode Exit fullscreen mode

Intent:

define trajectory-driven development
Enter fullscreen mode Exit fullscreen mode

Behavior:

research
→ formalize
→ define vocabulary
→ define grammar
→ implement parser
→ implement validator
→ generate artifacts
→ execute
→ observe
→ compare
Enter fullscreen mode Exit fullscreen mode

Evidence:

specification.valid
grammar.valid
examples.valid
implementation.generated
tests.pass
trajectory.conforms
Enter fullscreen mode Exit fullscreen mode

Assim:

T-DD
Enter fullscreen mode Exit fullscreen mode

pode ser utilizado para desenvolver:

T-DD itself
Enter fullscreen mode Exit fullscreen mode

43. Um exemplo completo

Considere:

"Preciso de uma entrega."

A mensagem é:

"Preciso de uma entrega"
Enter fullscreen mode Exit fullscreen mode

Destiny 

delivery.requested
delivery.paid
delivery.assigned
delivery.tracked
delivery.delivered
delivery.settled
Enter fullscreen mode Exit fullscreen mode

Intent 

customer → deliver(package, origin, destination)
Enter fullscreen mode Exit fullscreen mode

Missing semantic information 

origin
destination
Enter fullscreen mode Exit fullscreen mode

Behavior 

request
→ collect
→ discover
→ select
→ charge
→ confirm
→ release
→ track
→ validate
→ settle
Enter fullscreen mode Exit fullscreen mode

Contract 

release requires payment.confirmed
Enter fullscreen mode Exit fullscreen mode

State 

requested
→ collecting
→ searching
→ assigned
→ awaiting_payment
→ paid
→ active
→ delivered
→ settled
Enter fullscreen mode Exit fullscreen mode

Actor 

customer:
    request
    pay
    validate

system:
    classify
    collect
    discover
    select
    release
    route
    settle

courier:
    accept
    locate
    deliver

payment:
    confirm
    reject
Enter fullscreen mode Exit fullscreen mode

Evidence 

intent.recognized
addresses.collected
courier.selected
payment.confirmed
delivery.released
location.received
code.validated
settlement.completed
Enter fullscreen mode Exit fullscreen mode

Trajectory 

customer.request
→ system.collect
→ system.discover
→ system.select
→ customer.pay
→ payment.confirm
→ system.release
→ courier.locate*
→ system.relay*
→ customer.code
→ system.validate
→ system.settle
Enter fullscreen mode Exit fullscreen mode

Implementation

Somente agora:

WhatsApp
→ classifier
→ orchestrator
→ skill runtime
→ payment provider
→ courier service
→ PostgreSQL
→ event stream
→ observability
Enter fullscreen mode Exit fullscreen mode

A tecnologia é uma realização da trajetória, não sua definição.

44. T-DD e o problema do "happy path"

Uma consequência importante é que a trajetória não deve representar apenas:

happy path
Enter fullscreen mode Exit fullscreen mode

Deve representar:

valid trajectories
+
invalid trajectories
+
recovery trajectories
Enter fullscreen mode Exit fullscreen mode

Por exemplo:

payment rejected
Enter fullscreen mode Exit fullscreen mode

pode produzir:

awaiting_payment
→ payment_rejected
→ retry_payment
→ payment_confirmed
Enter fullscreen mode Exit fullscreen mode

Enquanto:

courier unavailable
Enter fullscreen mode Exit fullscreen mode

pode produzir:

searching
→ no_courier
→ expand_search
→ searching
Enter fullscreen mode Exit fullscreen mode

Portanto:

T-DD specification
Enter fullscreen mode Exit fullscreen mode

deve ser capaz de representar um espaço de trajetórias.

45. Trajectory Space

Podemos definir:

𝒯(I)
Enter fullscreen mode Exit fullscreen mode

como o conjunto de trajetórias admissíveis para uma intenção I.

Então:

τ ∈ 𝒯(I)
Enter fullscreen mode Exit fullscreen mode

significa:

τ é uma trajetória semanticamente válida para realizar I.

Uma implementação pode produzir:

τ₁
Enter fullscreen mode Exit fullscreen mode

e outra:

τ₂
Enter fullscreen mode Exit fullscreen mode

sem que ambas sejam idênticas.

O que importa é:

τ₁ ∈ 𝒯(I)
τ₂ ∈ 𝒯(I)
Enter fullscreen mode Exit fullscreen mode

Isso fornece uma fundamentação matemática para não confundir:

semantic equivalence
Enter fullscreen mode Exit fullscreen mode

com:

implementation equality
Enter fullscreen mode Exit fullscreen mode

46. Equivalência de trajetórias

Duas trajetórias podem ser diferentes e semanticamente equivalentes.

Exemplo:

Trajectory A:

discover courier
→ select courier
→ charge
Enter fullscreen mode Exit fullscreen mode

e:

Trajectory B:

discover courier
→ reserve courier
→ charge
→ confirm reservation
Enter fullscreen mode Exit fullscreen mode

Se ambas preservarem as mesmas invariantes e produzirem o mesmo destino:

A ≈ B
Enter fullscreen mode Exit fullscreen mode

podem ser consideradas semanticamente equivalentes sob uma relação de equivalência definida pelo domínio.

Isso abre uma área de pesquisa:

trajectory equivalence
Enter fullscreen mode Exit fullscreen mode

análoga a relações de equivalência em sistemas formais, linguagens e processos concorrentes.

47. Conformance como refinement

Podemos interpretar implementação como refinamento:

Specification
      ↓
Refinement
      ↓
Implementation
Enter fullscreen mode Exit fullscreen mode

Uma implementação correta não deveria introduzir comportamentos proibidos.

Portanto:

Allowed(T)
Enter fullscreen mode Exit fullscreen mode

deve conter o comportamento observado:

Observed(T) ⊆ Allowed(T)
Enter fullscreen mode Exit fullscreen mode

com condições adicionais para cobertura:

Required(T) ⊆ Observed(T)
Enter fullscreen mode Exit fullscreen mode

Uma implementação idealmente satisfaz:

Required(T)
    ⊆
Observed(T)
    ⊆
Allowed(T)
Enter fullscreen mode Exit fullscreen mode

Essa fórmula resume de maneira compacta uma propriedade importante do T-DD:

a execução deve realizar o que é necessário sem produzir aquilo que é proibido.

48. Required, Allowed e Forbidden

Podemos formalizar:

R = required behavior
A = allowed behavior
F = forbidden behavior
Enter fullscreen mode Exit fullscreen mode

com:

R ⊆ A
F ∩ A = ∅
Enter fullscreen mode Exit fullscreen mode

E:

Observed ⊆ A
Enter fullscreen mode Exit fullscreen mode

e:

R ⊆ Observed
Enter fullscreen mode Exit fullscreen mode

para uma trajetória totalmente conforme.

Quando:

Observed ∩ F ≠ ∅
Enter fullscreen mode Exit fullscreen mode

temos uma violação explícita.

Quando:

R - Observed ≠ ∅
Enter fullscreen mode Exit fullscreen mode

temos comportamento ausente.

Isso fornece uma base formal simples para um futuro T-DD Conformance Engine.

49. O loop completo

A metodologia pode ser representada por:

DESTINY
   ↓
INTENT
   ↓
BEHAVIOR
   ↓
EVIDENCE
   ↓
CONTRACT
   ↓
STATE
   ↓
ACTOR
   ↓
SKILL
   ↓
TRAJECTORY
   ↓
DSL
   ↓
IMPLEMENT
   ↓
EXECUTE
   ↓
OBSERVE
   ↓
RECONSTRUCT
   ↓
COMPARE
   ↓
CONFORMANCE
   ↓
REPLAN / REPAIR
   └───────────────────↺
Enter fullscreen mode Exit fullscreen mode

Ou, de maneira mais abstrata:

declare
   ↓
refine
   ↓
project
   ↓
execute
   ↓
observe
   ↓
compare
   ↓
adapt
Enter fullscreen mode Exit fullscreen mode

50. O que diferencia T-DD das metodologias existentes

Abordagem Artefato central Pergunta principal
TDD Teste O código satisfaz o teste?
BDD Behavior/scenario O sistema apresenta o comportamento esperado?
DDD Domain model Qual é o modelo do domínio?
MDD Model Como gerar/derivar implementação do modelo?
Design by Contract Contract Quais condições devem ser verdadeiras?
Statecharts State machine Quais estados/transições são possíveis?
Event Sourcing Event history Como chegamos ao estado atual?
Process Mining Event log/process model Como o processo realmente acontece?
Goal-oriented RE Goal Qual objetivo precisa ser realizado?
T-DD Trajectory Como uma intenção válida evolui até um destino sob restrições verificáveis?

Essa tabela não afirma que T-DD substitui as demais.

A proposta é que essas técnicas possam se tornar projeções ou mecanismos auxiliares dentro de uma especificação de trajetória.

51. O papel da trajetória como novo artefato de primeira classe

A proposição central pode ser reduzida a:

Software system
=
implementation
+
semantic trajectory
Enter fullscreen mode Exit fullscreen mode

e não simplesmente:

Software system
=
code
Enter fullscreen mode Exit fullscreen mode

ou:

Software system
=
current state
Enter fullscreen mode Exit fullscreen mode

A trajetória representa:

what was intended
+
what was allowed
+
what was done
+
by whom
+
when
+
under which state
+
with what evidence
+
toward which destination
Enter fullscreen mode Exit fullscreen mode

Essa é uma quantidade de informação que um estado final sozinho não consegue representar.

52. A contribuição conceitual

É importante separar a contribuição do T-DD daquilo que já existe.

Não seria correto afirmar:

"ninguém antes estudou trajetórias, intenções, estados, contratos ou processos".

Isso seria falso.

Existem décadas de pesquisa sobre:

  • intenção;
  • objetivos;
  • processos;
  • workflows;
  • máquinas de estados;
  • lógica temporal;
  • contratos;
  • traceability;
  • process mining;
  • intenção em engenharia de software;
  • comportamento;
  • event sourcing.

Inclusive, trabalhos recentes propõem explicitamente uma visão de intentions in software engineering, argumentando que features, requirements, issues, mudanças e bugs podem ser compreendidos como diferentes abstrações relacionadas às intenções dos stakeholders. A Vision on Intentions in Software Engineering

A contribuição específica do T-DD está na composição:

Destiny
+
Intent
+
Behavior
+
Evidence
+
Contract
+
State
+
Actor
+
Skill
+
Trajectory
+
DSL
+
Conformance
Enter fullscreen mode Exit fullscreen mode

como uma única cadeia metodológica na qual cada camada refina a anterior.

53. Uma relação particularmente importante com pesquisa contemporânea sobre intenções

A pesquisa A Vision on Intentions in Software Engineering é especialmente próxima do T-DD.

Os autores argumentam que diversos artefatos utilizados no desenvolvimento de software carregam implicitamente intenções de stakeholders e propõem mecanismos para declarar, rastrear e verificar essas intenções durante a evolução do software. A Vision on Intentions in Software Engineering

Isso converge fortemente com:

Intent
 ↓
Specification
 ↓
Change
 ↓
Verification
Enter fullscreen mode Exit fullscreen mode

do T-DD.

A diferença é que o T-DD introduz uma dimensão adicional:

Intent
 ↓
Trajectory
 ↓
Observed realization
Enter fullscreen mode Exit fullscreen mode

Ou seja, não apenas:

"esta mudança corresponde à intenção?"
Enter fullscreen mode Exit fullscreen mode

mas:

"esta execução realizou a intenção através de uma trajetória semanticamente válida?"
Enter fullscreen mode Exit fullscreen mode

54. T-DD como ponte entre intenção e execução

Podemos finalmente formular:

Intent
    ↓
semantic constraints
    ↓
trajectory space
    ↓
execution
    ↓
observed trajectory
    ↓
conformance
Enter fullscreen mode Exit fullscreen mode

Isso fornece uma ponte entre níveis que tradicionalmente ficam separados:

Human meaning
       ↓
Requirements
       ↓
Design
       ↓
Code
       ↓
Runtime
       ↓
Telemetry
Enter fullscreen mode Exit fullscreen mode

T-DD tenta transformar essa cadeia em:

Human intention
       ↓
Semantic trajectory
       ↓
Executable specification
       ↓
Runtime execution
       ↓
Observable trajectory
       ↓
Formal comparison
Enter fullscreen mode Exit fullscreen mode

55. Princípios normativos do T-DD

Uma implementação que siga T-DD deve observar, idealmente, os seguintes princípios.

55.1 Semântica antes da tecnologia 

meaning → implementation
Enter fullscreen mode Exit fullscreen mode

e não:

technology → inferred meaning
Enter fullscreen mode Exit fullscreen mode

55.2 Intenção não é execução 

intent ≠ behavior
Enter fullscreen mode Exit fullscreen mode

55.3 Estado final não é histórico 

state ≠ trajectory
Enter fullscreen mode Exit fullscreen mode

55.4 Evidência faz parte da especificação 

behavior without evidence
Enter fullscreen mode Exit fullscreen mode

é incompleto quando a verificabilidade é necessária.

55.5 Autoridade deve ser explícita 

actor → capability
Enter fullscreen mode Exit fullscreen mode

55.6 Contratos são restrições semânticas 

contract → legal execution boundary
Enter fullscreen mode Exit fullscreen mode

55.7 Trajetórias podem ser alternativas 

one intent
→ multiple valid trajectories
Enter fullscreen mode Exit fullscreen mode

55.8 Falhas são parte do modelo 

failure
→ trajectory branch
Enter fullscreen mode Exit fullscreen mode

55.9 Implementação é uma projeção 

semantic model → implementation
Enter fullscreen mode Exit fullscreen mode

55.10 Execução deve ser comparável com a declaração 

declared trajectory
↔
observed trajectory
Enter fullscreen mode Exit fullscreen mode

56. A definição final

Uma definição formal resumida pode ser:

Trajectory-Driven Development é um método de desenvolvimento de software no qual o sistema é progressivamente refinado a partir de destinos e intenções semânticas em comportamentos, evidências, contratos, estados, autoridades, capacidades e trajetórias declaradas, das quais implementações executáveis são derivadas e contra as quais as trajetórias observadas podem ser verificadas quanto à conformidade.

Em notação:

T-DD =
    Semantic Declaration
    +
    Monotonic Refinement
    +
    Executable Projection
    +
    Runtime Observation
    +
    Trajectory Conformance
Enter fullscreen mode Exit fullscreen mode

E sua propriedade fundamental:

Implementation ⊨ ObservedTrajectory
             ⊨ DeclaredTrajectory
             ⊨ Behavior
             ⊨ Intent
             ⊨ Destiny
Enter fullscreen mode Exit fullscreen mode

57. A tese central

O T-DD pode ser resumido em uma única afirmação:

Software não deve ser especificado apenas pelo que ele contém ou pelo estado em que termina, mas também pela trajetória semanticamente válida através da qual realiza uma intenção e alcança um destino.

Ou, de forma ainda mais curta:

Don't only specify the state.

Specify the trajectory.
Enter fullscreen mode Exit fullscreen mode

E, para sistemas agentes:

Don't only constrain what the agent can do.

Constrain the trajectory through which
the agent may realize the intent.
Enter fullscreen mode Exit fullscreen mode

58. Relações científicas fundamentais

A fundamentação do T-DD pode ser organizada assim:

PSICOLOGIA
    Intentions
    ↓
    Behavior
    ↓
    Goal pursuit

SOCIOLOGIA
    Actor
    ↓
    Action
    ↓
    Context
    ↓
    Consequence

REQUIREMENTS ENGINEERING
    Goal
    ↓
    Requirement
    ↓
    Traceability

FORMAL METHODS
    State
    ↓
    Transition
    ↓
    Contract
    ↓
    Temporal Logic

PROCESS SCIENCE
    Process Model
    ↓
    Event Log
    ↓
    Conformance

COMPUTER SCIENCE
    Trace
    ↓
    Execution
    ↓
    Verification

T-DD
    Destiny
    ↓
    Intent
    ↓
    Behavior
    ↓
    Evidence
    ↓
    Contract
    ↓
    State
    ↓
    Actor
    ↓
    Skill
    ↓
    Trajectory
    ↓
    Implementation
    ↓
    Observed Trajectory
    ↓
    Conformance
Enter fullscreen mode Exit fullscreen mode

A proposta, portanto, não surge isoladamente. Ela funciona como uma síntese arquitetural de linhas de pesquisa que normalmente aparecem separadas.

59. Referências fundamentais

Engenharia de software e métodos formais

Hoare, C. A. R. — An Axiomatic Basis for Computer Programming (1969).
Fundamentação da lógica de Hoare e do raciocínio formal sobre propriedades de programas. ACM / referência bibliográfica

Meyer, Bertrand — Applying "Design by Contract" (1992).
Fundamentação de contratos, invariantes, pré-condições e pós-condições.

Harel, David — Statecharts: A Visual Formalism for Complex Systems (1987).
Fundamentação para especificação de sistemas comportamentais complexos utilizando estados, hierarquia, concorrência e comunicação.

Pnueli / Clarke / Emerson / Sifakis — Temporal Logic and Model Checking.
Base formal para verificar propriedades sobre sequências de estados e comportamentos temporais.

Requirements Engineering

Gotel, O.; Finkelstein, A. — An Analysis of the Requirements Traceability Problem (1994).
Fundamentação do problema de rastreabilidade entre intenção/requisito e artefatos posteriores.

van Lamsweerde, Axel — Goal-Oriented Requirements Engineering.
Fundamentação para derivação orientada a objetivos. Goal-Oriented Requirements Engineering

Horkoff et al. — Goal-oriented requirements engineering: an extended systematic mapping study.
Mapeamento sistemático da área de engenharia de requisitos orientada a objetivos. Requirements Engineering / DOI

Process Mining

van der Aalst, W.; Weijters, T.; Maruster, L. — Workflow Mining: Discovering Process Models from Event Logs (2004).
Fundamentação de descoberta de processos a partir de logs.

van der Aalst, W. — Process Mining: Discovery, Conformance and Enhancement of Business Processes.
Obra fundamental sobre descoberta, conformidade e evolução de processos. Process Mining — Springer

van der Aalst, Adriansyah, van Dongen — Replaying History on Process Models for Conformance Checking and Performance Analysis.
Particularmente relevante para o conceito de comparar trajetória observada contra trajetória declarada. Artigo sobre conformance checking

Ghasemi; Amyot — From Event Logs to Goals: A Systematic Literature Review of Goal-Oriented Process Mining.
Conecta diretamente event logs, objetivos e process mining. Artigo / DOI

Khodabandelou et al. — Unsupervised Discovery of Intentional Process Models from Event Logs.
Particularmente relevante para a relação entre intenções e trajetórias observadas. ACM Digital Library

Psicologia e comportamento

Ajzen, Icek — The Theory of Planned Behavior (1991).
Fundamentação para a distinção entre intenção, comportamento e controle percebido.

Essa referência é importante para o T-DD porque impede uma simplificação perigosa:

intent → guaranteed action
Enter fullscreen mode Exit fullscreen mode

A literatura sustenta uma formulação mais cuidadosa:

intent → propensity toward behavior
Enter fullscreen mode Exit fullscreen mode

O T-DD transforma essa distinção em uma preocupação computacional:

intent
→ admissible behavior
→ executable trajectory
→ observed behavior
Enter fullscreen mode Exit fullscreen mode

Sociologia, interação e ação situada

Suchman, Lucy — Plans and Situated Actions.

A obra é relevante para a distinção entre uma especificação abstrata e a realização situada dessa especificação. Para T-DD, isso reforça:

Trajectory specification
≠
fixed execution script
Enter fullscreen mode Exit fullscreen mode

Uma trajetória pode definir invariantes e condições de realização sem obrigar uma única estratégia operacional.

Event Sourcing

Fowler, Martin — Event Sourcing.

Event Sourcing fornece um mecanismo para preservar a sequência histórica de mudanças e reconstruir estados anteriores.

A relação com T-DD é:

Event Sourcing
→ observed execution history

T-DD
→ semantic expected trajectory
Enter fullscreen mode Exit fullscreen mode

A combinação dos dois permite:

ExpectedTrajectory
        ↕
ObservedEventHistory
        ↓
Conformance
Enter fullscreen mode Exit fullscreen mode

60. Fonte canônica da implementação

A implementação experimental e a evolução atual da DSL estão no repositório:

Intent-Trajectory-Driven-Development — GitHub

A documentação atual já contém:

Destiny
Intent
Behavior
Evidence
Contract
State
Actor
Skill
Trajectory
DSL
Execution
Enter fullscreen mode Exit fullscreen mode

além de exemplos .itdsl e áreas de RFC/SRFC. README.md atual

61. Próxima fronteira conceitual

A partir dessa definição, o próximo passo natural não é simplesmente criar mais sintaxe.

É formalizar:

Trajectory Algebra
Enter fullscreen mode Exit fullscreen mode

com operações como:

compose(T₁,T₂)
branch(T₁,T₂)
merge(T₁,T₂)
repeat(T)
optional(T)
alternative(T₁,T₂)
refine(T)
observe(T)
compare(T₁,T₂)
repair(T₁,T₂)
Enter fullscreen mode Exit fullscreen mode

e propriedades:

trajectory equivalence
trajectory refinement
trajectory conformance
trajectory distance
trajectory completeness
trajectory validity
trajectory authorization
trajectory temporal consistency
Enter fullscreen mode Exit fullscreen mode

A partir daí, o T-DD deixa de ser apenas uma metodologia textual e começa a se tornar uma teoria computacional de trajetórias comportamentais.

A arquitetura final pode então ser expressa como:

                 ┌───────────────┐
                 │    DESTINY    │
                 └───────┬───────┘
                         ↓
                 ┌───────────────┐
                 │    INTENT     │
                 └───────┬───────┘
                         ↓
                 ┌───────────────┐
                 │   BEHAVIOR    │
                 └───────┬───────┘
                         ↓
                 ┌───────────────┐
                 │   CONTRACT    │
                 └───────┬───────┘
                         ↓
                 ┌───────────────┐
                 │     STATE     │
                 └───────┬───────┘
                         ↓
                 ┌───────────────┐
                 │     ACTOR     │
                 └───────┬───────┘
                         ↓
                 ┌───────────────┐
                 │     SKILL     │
                 └───────┬───────┘
                         ↓
                 ┌───────────────┐
                 │  TRAJECTORY   │
                 └───────┬───────┘
                         ↓
                 ┌───────────────┐
                 │      DSL      │
                 └───────┬───────┘
                         ↓
                 ┌───────────────┐
                 │ IMPLEMENTATION│
                 └───────┬───────┘
                         ↓
                 ┌───────────────┐
                 │   OBSERVED    │
                 │   TRAJECTORY  │
                 └───────┬───────┘
                         ↓
                 ┌───────────────┐
                 │  CONFORMANCE  │
                 └───────┬───────┘
                         │
                ┌────────┴────────┐
                ↓                 ↓
             CONFORM           DEVIATE
                                  ↓
                             REPLAN / REPAIR
                                  │
                                  └──────↺
Enter fullscreen mode Exit fullscreen mode

A hipótese central do T-DD pode finalmente ser expressa em uma única fórmula:

Correct Software
=
Implementation
⊨
Observed Trajectory
⊨
Declared Trajectory
⊨
Behavior
⊨
Intent
⊨
Destiny
Enter fullscreen mode Exit fullscreen mode

Ou, em termos de engenharia:

O código é apenas uma realização. A trajetória é o objeto que permite relacionar intenção, comportamento, estado, autoridade, evidência e destino em uma estrutura que pode ser executada, observada, comparada e formalmente verificada.

Top comments (0)