Table of Contents

Compreendendo DODAF: A Fundação para Diagramas OV e SV

O Departamento de Arquitetura de Defesa (DODAF) fornece uma metodologia estruturada para projetar, avaliar e comunicar sistemas complexos dentro dos setores de defesa e aeroespacial. Fundada para garantir que as descrições de arquitetura sejam consistentes, reutilizáveis e alinhadas com as necessidades dos stakeholders, o DODAF é organizado em seis pontos de vista: All Viewpoint (AV), Capability Viewpoint (CV), Operational Viewpoint (OV), Project Viewpoint (PV), Systems Viewpoint (SV) e Standards Viewpoint (StdV). Entre estes, o OV e SV são os mais utilizados para vincular necessidades operacionais às soluções técnicas do sistema.

A Vista Operacional (OV) descreve os conceitos operacionais, atividades, tarefas e fluxos de informação necessários para realizar missões. Concentra-se no que precisa ser feito, por quem, e com que informação. A Vista de Sistemas (SV) documenta, por sua vez, os sistemas físicos e lógicos, as suas interfaces e as trocas que apoiam as atividades operacionais. Uma visão crítica para os arquitetos é que o SV deve rastrear diretamente para o OV; todas as funções do sistema devem existir para satisfazer pelo menos uma atividade operacional. Esta rastreabilidade é formalizada através de matrizes como a Atividade Operacional para Sistemas Matriz de Rastreabilidade de Funções (SV-5).

O desenvolvimento de diagramas OV e SV permite que os interessados compreendam corretamente as dependências, identifiquem lacunas de capacidade, avaliem alternativas e informem as decisões de aquisição. As seguintes secções fornecem um mergulho profundo nos produtos dentro de cada vista e uma metodologia prática, passo a passo, para construí-los.

A visão operacional (OV) em profundidade

O DODAF define sete produtos OV padrão, cada um servindo um propósito distinto. Embora nem todos os projetos exijam todos os produtos, uma arquitetura madura normalmente inclui pelo menos OV-1, OV-2, OV-5, e OV-6.

OV-1: Gráfico de Conceito Operacional de Alto Nível

O OV-1 é uma representação pictórica do conceito operacional. Mostra os principais nós operacionais (por exemplo, sede, plataformas de sensores, centros de comando), o seu arranjo geográfico ou lógico e as trocas de informação de alto nível. As partes interessadas primárias, os decisores superiores e os patrocinadores não técnicos, utilizam o OV-1 para compreender rapidamente o âmbito da missão e os papéis das entidades participantes. Um OV-1 bem construído usa ícones, rótulos e uma narrativa de contexto claros para contar a história operacional sem exigir profundo conhecimento técnico.

OV-2: Descrição do Fluxo de Recursos Operacionais

OV-2 acrescenta fluxos de informação detalhados entre nós operacionais. Identifica os recursos específicos (informação, material, pessoal) que fluem através de interfaces. Para cada fluxo, o arquiteto documenta os nós produtor e consumidor, a frequência e a natureza do recurso (por exemplo, dados de sensores, ordens logísticas, relatórios de consciência situacional). Este produto torna-se a base para diagramas posteriores SV-1 e SV-2, garantindo que as interfaces do sistema implementem exatamente as trocas operacionais necessárias.

OV-3: Matriz de fluxo de recursos operacionais

OV-3 é uma representação tabular das informações contidas no OV-2. Ele lista todos os fluxos de recursos linha a linha, especificando fonte, destino, formato de dados, atributos de qualidade e classificação de segurança. Esta matriz suporta análises detalhadas, como equilíbrio de fluxo de dados, cálculos de rendimento e auditorias de classificação de segurança.

OV-4: Gráfico de Relações Organizacionais

OV-4 descreve a estrutura de comando, as relações e as linhas de autoridade entre os nós operacionais. Responde: quem está no comando, quem relata a quem, e que mecanismos de coordenação existem? O gráfico pode ser hierárquico (desagregação organizacional) ou mais dinâmico (relações de ligação, equipes organizadas por tarefas).

OV-5a e OV-5b: Modelos de Atividade Operacional

OV-5a (Árvore de Descomposição de Atividade Operacional) descompõe a missão de alto nível em atividades de nível inferior. OV-5b (Modelo de Atividade Operacional) mostra a sequência, entradas/saídas e performers de cada atividade. Juntos, eles descrevem o comportamento funcional da operação. Ao desenvolver o OV-5, use linguagem orientada para ação padrão (pares de substantivos) e assegure que cada atividade possa ser ligada a pelo menos uma função do sistema mais tarde no SV.

OV-6a, OV-6b, OV-6c: Regras Operacionais, Transições Estaduais e Modelos de Evento-Traço

Os produtos OV-6 captam restrições comportamentais e dinâmicas. OV-6a documenta regras de negócio e restrições operacionais (por exemplo, “Se a aeronave se aproximar dentro de 10 milhas náuticas, emitir aviso”). OV-6b (Descrição de Transição de Estado) modela os possíveis estados de nós operacionais e transições permitidas. OV-6c (Descrição de Eventos) usa diagramas de sequência para mostrar trocas ordenadas no tempo entre nós. Estes modelos são essenciais para validar a lógica operacional e para especificar o comportamento do sistema na série SV-10.

A Vista de Sistemas (SV) na Profundidade

A Vista de Sistemas compreende pelo menos dez produtos, desde SV-1 até SV-10c. A Vista de Sistemas deve demonstrar como os sistemas realizam as atividades operacionais e os fluxos de recursos definidos na OV.

SV-1: Descrição da Interface de Sistemas

SV-1 é a espinha dorsal estrutural da arquitetura do sistema. Representa sistemas (hardware, software, bases de dados) como nós e mostra as interfaces lógicas e físicas entre eles. Cada interface é marcada com os recursos que fluim através dele, o que deve corresponder aos fluxos de recursos documentados em OV-2. Os arquitetos usam SV-1 para identificar interfaces em falta, pontos de falha e redundância desnecessária.

SV-2: Sistema de Sistema de Fluxo de Recursos Descrição

O SV-2 adiciona detalhes adicionais a cada interface mostrada em SV-1. Especifica pilhas de protocolo, tipos de link de dados, largura de banda e atributos de qualidade de serviço. Por exemplo, uma interface entre um sistema de controle de terra e um UAV pode ser descrita como “Link 16, 1 Mbps, criptografado, com latência máxima de 200 ms”. Este produto se alimenta diretamente em estudos de engenharia de sistemas e avaliações de interoperabilidade.

SV-3: Matriz de Sistemas-Sistemas

SV-3 é uma matriz que mostra quais pares de sistemas têm interfaces, e opcionalmente a natureza dessas interfaces (por exemplo, bidirecional, unidirecional, frequência de rádio, com fio). A matriz ajuda os arquitetos a identificar rapidamente lacunas de interface ou acoplamento excessivo.

SV-4: Descrição da Funcionalidade dos Sistemas

O SV-4 decompõe cada sistema nas suas funções. Ao contrário do OV-5, que se concentra em atividades operacionais, o SV-4 foca no que o sistema faz: por exemplo, “computar solução de controle de fogo”, “sensor de manobra”, “manter ligação”. Funções em SV-4 devem ser rastreáveis para atividades em OV-5 via SV-5.

SV-5: Atividade Operacional para Matriz de Rastreabilidade de Funções de Sistemas

O SV-5 é um dos produtos mais críticos para a consistência. Ele mapeia cada atividade operacional em OV-5a para uma ou mais funções do sistema em SV-4. Um SV-5 completo garante que todas as necessidades operacionais sejam satisfeitas por alguma capacidade do sistema. As lacunas indicam que uma função necessária está faltando no design do sistema. Mapeamentos redundantes podem sugerir oportunidades de consolidação.

SV-6: Matriz de fluxo de recursos de sistemas

SV-6 é a contraparte orientada para sistemas de OV-3. Ele lista todos os fluxos de recursos entre sistemas, ligando cada um às interfaces definidas em SV-1. Mantenha consistência: cada fluxo em OV-3 que é automatizado deve ter um fluxo correspondente em SV-6.

SV-7: Matriz de Medidas de Sistemas

SV-7 documenta parâmetros de desempenho como rendimento, confiabilidade, latência, velocidade de processamento e capacidade. Estas medidas estão ligadas às funções do sistema e permitem trocas quantitativas. Por exemplo, uma função de radar pode ter uma medida de “intervalo de detecção: 500 km a 90% de probabilidade”. Alinhamento com objetivos de desempenho definidos por stakeholder é uma atividade de análise chave.

SV-10a, SV-10b, SV-10c: Regras de Sistemas, Transições Estaduais e Modelos de Evento-Traço

Estes produtos espelham o OV-6 mas no nível do sistema. SV-10a define regras de negócio ou restrições de nível do sistema. SV-10b modela as máquinas de estado para cada sistema ou função. SV-10c usa diagramas de sequência para ilustrar trocas de mensagens ordenadas no tempo entre interfaces de sistema. Juntos, eles validam que o comportamento do sistema coletivo satisfaz a dinâmica operacional descrita em OV-6.

Uma metodologia passo a passo para o desenvolvimento de diagramas OV e SV

O método a seguir combina decomposição de cima para baixo com refinamento orientado pelas partes interessadas. Ele foi projetado para produzir diagramas consistentes e validados que suportam tanto a análise quanto a comunicação.

Etapa 1: Defina o objetivo e o escopo

Antes de desenhar qualquer diagrama, responda a três perguntas: Qual é a missão ou problema que a arquitetura aborda? Qual é o uso pretendido da arquitetura (por exemplo, suporte à aquisição, análise de gap, avaliação de interoperabilidade)? Quais são os limites - organizacional, geográfico, temporal? Defina-os na Descrição de Arquitetura (AV-1). Isso evita o fluência do escopo e garante que diagramas posteriores permaneçam focados.

Etapa 2: Identificar os interessados e suas preocupações

Os participantes incluem comandantes operacionais, engenheiros de sistemas, gestores de programas e funcionários de aquisição. Cada um tem preocupações específicas: os comandantes precisam ver a flexibilidade operacional; os engenheiros exigem definições detalhadas de interface; os gestores querem implicações de risco e custo. Documente essas preocupações e mapeá-las para os produtos OV e SV que os abordam. Este mapeamento torna-se a base para a sua seleção de diagramas.

Etapa 3: Construir o Conceito Operacional de Alto Nível (OV-1)

Crie o gráfico OV-1 usando uma ferramenta de desenho simples ou um ambiente baseado em modelos. Coloque os nós operacionais primários (por exemplo, Força de Tarefa Conjunta, Nave de Superfície, Veículo Aéreo não Tripulado, Satélite) e mostre as trocas de informações de alto nível. Adicione uma descrição textual que capture o cenário operacional. Reveja com os stakeholders operacionais para validar a narrativa. O OV-1 é muitas vezes revisado várias vezes, uma vez que as etapas posteriores revelam elementos ausentes.

Etapa 4: Modelar as Atividades Operacionais e Fluxos de Recursos (OV-2, OV-5a/b)

Utilizando o OV-1 como esqueleto, decompõe cada nó operacional nas suas actividades utilizando uma decomposição funcional (OV-5a). Para cada actividade, determina entradas e saídas. Depois adiciona os fluxos de recursos entre nós em OV-2. Por exemplo, se a actividade “Formular Resposta” num nó produz um “Plano de Resposta”, esse plano deve fluir para outro nó. Documentar as características de cada fluxo (frequência, volume de dados, segurança). Validar estes fluxos com especialistas em matérias de assunto.

Etapa 5: Definir relações organizacionais (OV-4)

Adicione as linhas de autoridade e relatórios entre nós. Isto pode ser simples (hierarquia) ou complexo (parceiros de coalizão com comando compartilhado). OV-4 ajuda a identificar quais nós estão autorizados a solicitar ou receber quais recursos – informações muitas vezes críticas para regras de controle de acesso em SV-10a.

Etapa 6: Estabelecer Modelos Comportamentais (OV-6)

Para threads operacionais críticos, crie diagramas de estado (OV-6b) e diagramas de sequência (OV-6c). Por exemplo, um estado “não pronto” pode passar para “pronto” após receber uma mensagem de autorização. O diagrama de sequência pode mostrar as mensagens exatas entre nós ao longo do tempo, incluindo condições e exceções. Estes modelos são a especificação formal de operações e serão usados diretamente para conduzir o projeto do sistema.

Etapa 7: Descrições de Interface de Sistemas (SV–1)

Agora mude para o domínio do sistema. Identifique os sistemas que implementam os nós operacionais. Para cada nó operacional, listar os sistemas ou componentes do sistema (por exemplo, suite de software C2, rádio, servidor). Desenhe os sistemas como nós em SV-1 e conecte-os com interfaces que correspondam aos fluxos de recursos operacionais em OV-2. Rotule cada interface com o seu sistema de implementação e os recursos que carrega.

Nesta etapa, você pode descobrir que um único fluxo operacional deve ser dividido entre várias interfaces de sistema (por exemplo, voz e dados enviados por links separados).

Etapa 8: Funcionalidade e rastreabilidade dos sistemas de detalhes (SV-4, SV-5)

Decomponha cada sistema nas suas funções (SV-4). Por exemplo, o sistema “Ground Control Station” pode incluir funções como “Recebendo Telemetria”, “Atualizar o Banco de Dados” e “Transmitir Comandos”. Em seguida, crie a matriz SV-5 ligando cada função SV-4 a uma ou mais atividades OV-5. Esta etapa é onde as lacunas de rastreabilidade se tornam evidentes. Se uma atividade operacional necessária não tem função de sistema de suporte, você deve adicionar uma função ou argumentar que a atividade é manual.

Etapa 9: Sistemas de Modelo Fluxos de Recursos e Dinâmica (SV-2, SV-10)

Refinar cada interface em SV-1 com atributos técnicos detalhados em SV-2 (protocolo, segurança, desempenho). Em seguida, desenvolver modelos de estado e sequência de nível de sistema (SV-10b/c) que espelham os comportamentos operacionais de OV-6. Por exemplo, o mesmo diagrama de sequência de OV-6c deve agora ser alargado ao nível do sistema, mostrando nomes de mensagens, formatos de dados e requisitos de tempo. As regras SV-10a podem documentar restrições do sistema, como “a recepção de dados inválidos não deve causar uma falha do sistema”.

Passo 10: Validar, Refinar e Gerenciar a Configuração

Faça sessões de revisão com os stakeholders originais e especialistas em assuntos de assunto adicionais. Caminhe pelos produtos OV e SV em ordem, começando com OV-1, e confirme que cada elemento OV é abordado no SV, e que a solução SV é viável e compatível com as normas (StdV). Use esse feedback para atualizar diagramas, e depois baseie a arquitetura. Uma vez inicializada, implemente o controle de versão usando um sistema de configuração baseado em modelo. Quaisquer alterações aos requisitos operacionais devem propagar-se através dos produtos SV; use SV-5 como a âncora principal de rastreabilidade.

Melhores práticas e armadilhas comuns

Melhores Práticas

  • Use uma ferramenta baseada em modelos. Ferramentas como Modelador de Sistemas Cameo, MagicDraw ou Sparx Enterprise Architect com perfis UPDM/UAF reforçam a consistência, permitem a geração automatizada de relatórios (incluindo matrizes) e facilitam a rastreabilidade em produtos OV e SV.
  • Mantenha uma notação padrão. O Perfil Unificado para DoDAF/MODAF (UPDM) ou o Unified Architecture Framework (UAF) fornece estereótipos e tipos de diagramas padrão. Isso melhora a comunicação entre equipes e reduz a interpretação incorreta.
  • Comece com a necessidade operacional. Até engenheiros de sistemas experientes devem resistir ao salto direto para diagramas SV sem uma sólida fundação OV. OV-5 e OV-2 são os pontos de partida mais valiosos.
  • Mantenha diagramas úteis, não completos. É melhor ter um conjunto bem organizado de cinco produtos OV que são revistos e precisos do que gerar todos os 30 produtos standard com qualidade mínima.
  • Suposições e decisões do documento. Cada diagrama deve ser acompanhado de uma narrativa que explique por que um determinado fluxo existe, por que uma função é atribuída a um determinado sistema, e quais pressupostos foram feitos sobre o ambiente operacional.

Pistácios comuns

  • Ignorar a consistência de visualização cruzada. O problema mais frequente nas arquiteturas DODAF são funções ou fluxos órfãos. Uma função do sistema em SV-4 que não tem atividade operacional principal em OV-5 é um desperdício, enquanto uma atividade operacional sem função rastreada indica um design incompleto do sistema. Use regras de validação automatizadas em sua ferramenta de modelagem para detectar esses problemas.
  • Sobrecomplicando OV-1. Algumas equipas tentam embalar demasiado detalhe no gráfico de conceito de alto nível, tornando-o ilegível. Mantenha OV-1 numa página; use OV-2 e OV-5 para detalhes.
  • Medidas de desempenho desprovidas de relevância (SV-7). Muitos projetos definem interfaces e funções, mas nunca anexam medidas. Sem SV-7, é impossível avaliar se o sistema atende aos requisitos operacionais.
  • Criando diagramas em isolamento. Se a equipe OV e SV não sincronizar regularmente, o SV irá derivar da realidade operacional. Avaliações conjuntas em cada etapa são essenciais.
  • Usando o nível errado de granularidade. Muito grosseira uma decomposição falha detalhes chave; muito fina uma decomposição torna a arquitetura descontrolada. Uma boa regra de polegar: cada atividade ou função deve representar um único comportamento coeso que pode ser atribuído a um único nó ou sistema de execução.

Ferramentas e Técnicas para Desenvolvimento de Diagramas DODAF

Embora seja possível criar diagramas DODAF com ferramentas de desenho genéricas (por exemplo, Microsoft Visio), a complexidade da rastreabilidade e do cruzamento torna as ferramentas baseadas em modelos fortemente recomendadas. As seguintes ferramentas suportam DODAF 2.02 e UAF:

  • Dassault Systèmes Cameo Systems Modeler (anteriormente MagicDraw) – amplamente utilizado em programas de defesa, suporta UPDM/UAF, fornece geração de matriz automatizada (SV-3, SV-5, OV-3), e pode gerar relatórios de arquitetura baseados na web.
  • Sparx Systems Enterprise Architect – oferece um complemento UAF maduro, suporta modelagem baseada em perfil e tem um ponto de custo mais baixo adequado para equipes menores.
  • IBM Engineering Rhapsody – forte em engenharia de sistemas com suporte SysML e pode ser configurado para pontos de vista DODAF.

Ao escolher uma ferramenta, avaliar sua capacidade de impor rastreabilidade, gerar matrizes SV-5, controlar versões e exportar para formatos padrão (por exemplo, HTML, XMI, PDF). Independentemente da ferramenta, a técnica chave é ] definir o metamodelo cedo: quais são os tipos de nós, fluxos e funções que você usará; quais relações (assinatura, rastreamento, interface) são permitidas; e quais atributos serão capturados. Este esforço inicial reduz significativamente o retrabalho.

Para equipas novas no DODAF, considere começar com um projecto piloto utilizando apenas OV-1, OV-2, OV-5, SV-1 e SV-5. Domine-as antes de adicionar modelos comportamentais e dinâmicos.

Conclusão

Desenvolver diagramas OV e SV do DODAF é um processo sistemático que liga os requisitos operacionais com o design do sistema técnico. Seguindo uma metodologia estruturada – desde a definição de escopo e construção de modelos operacionais, até o rastreamento de funções do sistema e validação com stakeholders – os arquitetos produzem diagramas precisos, abrangentes e acionáveis. O esforço investido na criação de produtos OV e SV de alta qualidade paga dividendos durante a aquisição, integração e gerenciamento do ciclo de vida do sistema. Os decisores obtêm uma compreensão clara de como os sistemas apoiam a missão, e os engenheiros têm uma especificação precisa para orientar o desenvolvimento. Para organizações de defesa e integradores de sistemas, dominar o desenvolvimento de OV e SV é uma competência essencial para fornecer capacidades bem sucedidas e interoperáveis.

Para mais informações, consultar o sítio oficial DoD Architecture Framework, o Unified Architecture Framework (UAF) especificação[, e o orientação do SEI sobre desenvolvimento de arquitetura do DODAF .