Capítulo 25 — Ateliê de projeto I

Mapa da aula

Aula 25 publicada. Mapa, exemplo, EX073.

flowchart TD
  N0["25.1 Problema do ateliê"]
  N1["25.2 Trade-offs"]
  N2["25.3 Registro de decisão"]
  N3["Nota prática"]
  N4["25.1b Cartões de restrição e galeria"]
  N5["Nota de campo — rotular antes do layout"]
  N6["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
  N6 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX073"]

Desenho lógico

flowchart LR
  N0["25.1 Problema do ateliê"]
  N1["25.2 Trade-offs"]
  N2["25.3 Registro de decisão"]
  N3["Nota prática"]
  N4["25.1b Cartões de restrição e galeria"]
  N5["Nota de campo — rotular antes do layout"]
  N6["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX073"]

[25.1 Problema do ateliê]
    |
    v
[25.2 Trade-offs]
    |
    v
[25.3 Registro de decisão]
    |
    v
[Nota prática]
    |
    v
[25.1b Cartões de restrição e galeria]
    |
    v
[Nota de campo — rotular antes do layout]
    |
    v
[Síntese]
    |
    v
[Exemplo resolvido] --> [Exercício EX073]

Objetivos de aprendizagem

Você vai (1) esboçar o pipeline de permitir/negar do monitor serial da ABP; (2) justificar os trade-offs numa breve revisão de projeto; (3) produzir um registro de decisão de uma página.

25.1 Problema do ateliê

Projeto: quadro de entrada para decodificação para carga do ConduitSet/lista de permissões para avaliação de permit() para emissão de evento para encaminhar ou descartar. Opções: política embutida no código versus arquivo de dados assinado; alertas síncronos versus assíncronos nas negações.

A equipe de ateliê de Lena na ABP esboça o caminho inteiro numa página e marca onde um quadro é negado se a política estiver ausente. As duas escolhas debatidas foram se a lista de permissões fica no código ou num arquivo de dados assinado, e se os alertas de negação são enviados de forma síncrona ou enfileirados. Cada opção é escrita com as suas consequências antes que alguém defenda uma delas.

25.2 Trade-offs

A política como dados assinados permite publicar atualizações sem reimplantar o firmware, mas exige verificação de assinatura e falha fechada em assinaturas ruins. Os alertas assíncronos escalam, mas podem chegar fora de ordem; para as negações no caminho do SIS, prefira o alerta síncrono.

A equipe de Lena concorda que uma assinatura ruim precisa parar todo o tráfego não essencial, exatamente como o requisito S-1 exige para uma política ausente. Os alertas síncronos ficam para as negações de códigos de escrita e para os caminhos ligados ao SIS, onde o atraso importa; as negações rotineiras de leitura são enfileiradas. A equipe também registra o que acontece se a chave de assinatura for perdida: o monitor mantém a última lista válida e alarma, e nenhuma atualização sem assinatura é aceita.

25.3 Registro de decisão

Uma página: contexto, opções, decisão, consequências, data, donos. Guarde ao lado do código.

Caso sintético — Ashford Batch Plant. O ateliê escolheu listas de permissões em JSON assinado, caminho síncrono para as negações que tocam códigos de escrita e lote assíncrono para as leituras rotineiras. O ADR-004 registra isso.

O ADR-004 registra nesse formato a decisão do ateliê sobre as listas de permissões em JSON assinado, com Lena e o líder da engenharia de controle como donos. Ele fica no repositório ao lado do código da política, para que qualquer pessoa que mude o carregador possa ler por que ele funciona do jeito que funciona.

25.4 Erros e limites

Ateliês que pulam os requisitos de segurança física produzem diagramas bonitos que falham abertos.

O ateliê de Lena se recusa a revisar um projeto até que ele mostre onde o monitor nega o tráfego quando a lista de permissões está ausente ou a sua assinatura falha. Os projetos que não conseguem responder voltam antes de qualquer discussão de layout ou ferramentas. Os cartões de restrição deixam os requisitos de segurança física visíveis na mesa desde o primeiro minuto, para que não sejam esquecidos no entusiasmo por uma arquitetura engenhosa. Os projetos rejeitados também são registrados.

Nota prática

Os facilitadores pausam a sala com: Onde negamos se a política estiver ausente? Se ninguém souber responder, a arquitetura não está pronta.

25.1b Cartões de restrição e galeria

Entregue a cada equipe do ateliê cartões de restrição: residência dos dados, operação por dois engenheiros, falha fechada, nada de pontuações vazias, independência do SIS. Projetos que violam um cartão são rejeitados antes do debate estético. Os ateliês terminam com uma galeria: as equipes expõem os rascunhos de ADR, e as outras tentam achar um caminho de falha aberta em cinco minutos.

Um esboço de ateliê precisa nomear por escrito as fronteiras de confiança, os repositórios de dados e o caminho de falha fechada. Dez minutos rotulando valem mais do que uma hora de layout estético. Os caminhos de falha aberta encontrados na galeria são escritos no ADR antes de ele ser aceito.

Nota de campo — rotular antes do layout

As equipes de ateliê que passaram os primeiros vinte minutos nomeando os pontos de negação e as fronteiras de confiança produziram ADRs que sobreviveram à revisão. As equipes que começaram pelas paletas de cores redescobriram caminhos de falha aberta durante a galeria. O CNHP agora exige um caminho de falha fechada rotulado na fotografia do quadro branco anexada a todo ADR.

Exercícios

• EX073 — Opções. Duas opções de entrega da política e um risco de cada. Rubrica: 3 = duas + riscos; 2 = opções; 1 = uma; 0 = nada.
• EX074 — ADR. Linha de decisão para os alertas síncronos de negação em códigos de escrita. Rubrica: 3 = decisão clara + porquê; 2 = só a decisão; 1 = vago; 0 = nada.
• EX075 — Revisão. Três perguntas que um revisor precisa fazer. Rubrica: 3 = falha fechada, autenticação da política, orçamento de latência; 2 = duas; 1 = uma; 0 = nada.

Síntese

O trabalho de ateliê termina numa decisão registrada, não numa impressão.