Antes de me aventurar no domínio de sistemas embarcados, trabalhei com desenvolvimento de sistemas financeiros e de administração público-privada. Diversas vezes, ao perguntar por modelos arquiteturais do sistema, era informado que ele era inexistente estava desatualizado. Depois de algum tempo nesse contexto, me juntei ao grupo de profissionais que acreditam que um bom código fonte e algumas linhas de comentário são suficientes enquanto documentação.

A realidade no domínio de embarcados é bem diferente. Entidades que regulamentam sistemas que, em caso de falha, causarão danos à pessoas ou ao meio-ambiente (mais conhecidos como sistemas safety-critical), exigem que as empresas que constroem esses sistemas sigam rigidamente as etapas dos processos de desenvolvimento, e gerem artefatos de documentação extremamente detalhados.

No caso de sistemas aviônicos, o DO-178B – Software Considerations in Airborne Systems and Equipment Certification, por exemplo, define processos rígidos para (i) Planejamento, (ii) Desenvolvimento, (iii) Requisitos, (iv) Design, (v) Codificação e Integração, (vi) Teste e Verificação, (vii) Gerencia de configuração, e (viii) Gerenciamento de qualidade. Para se ter uma ideia geral das etapas e artefatos, recomendo uma olhada na seguinte apresentação: Introduction to Avionic Systems Development.

Um dos artefatos exigidos pelo DO-178B é a documentação arquitetural dos vários sistemas que compõe um sistemas aviônico: diagramas de componentes, diagramas comportamentais de tempo-continuo e de estados, dentre outros.

Alem de servir para documentação, esses modelos são usados como base para geração de código funcional. Essa historia de geração automática de código soava um tanto quanto utópica para mim também, até que, certa vez, o chefe da engenharia de uma grande empresa de aviação me disse que não confiava em códigos escritos por desenvolvedores, mas sim em códigos gerados a partir de especificações arquiteturais. Tentando entender o que se passava na cabeça desse cidadão, comecei a me inteirar mais sobre o assunto, e me convenci do quão poderosos mecanismos de geração de código podem ser quando utilizados apropriadamente. Para uma visão prática sobre o assunto, recomendo conhecerem um pouco sobre ferramentas como OpenArchitectureware e Acceleo.

Esses modelos são também peças-chave nos processos de garantia de qualidade, que vão desde testes baseados em modelos à técnicas formais de Model-Checking (sim, estou falando de assuntos relacionados a métodos formais. Eles são amplamente utilizados na industria aviônica). Toda essa amarração exigida pelas normas regulatórias implica em lentidão no desenvolvimento, e, quando não gerido adequadamente, pode gerar atrasos consideráveis na entrega do produto (ver caso do Boeing 787 Dreamliner). No entanto, empresas que desenvolvem esses produtos muitas vezes optam por atrasos aceitáveis no time-to-markt, mas assegurar que os produtos são feitos como manda a norma; caso contrário, o prejuízo financeiro será ainda maior, e a reputação da empresa desaparece.

Aí vai um recado para turma do “anti-modelos-e-apenas-código-escrito-é-o-que-conta”: Sistemas dessa natureza não podem falhar! Não existe possibilidade de reiniciar o sistema de navegação ou de propulsão de uma aeronave enquanto ela voa a 900Km/h a uma altitude de 30000 pés. O custo de voltar a versão de um software depois que ele já foi inserido em uma família de jatos tem um custo que pode comprometer o projeto como um todo. Não estamos tratando de sistemas web; também não quero dizer que estes sejam menos complexos ou de menor importância; digo apenas que as restrições de domínio são mais rígidas, levando em conta as catástrofes causadas se um sistema desse falhar.