Se você está envolvido no desenvolvimento moderno de software, então você se preocupa com o OOT, ou “Tecnologia Orientada a Objetos”. Se o seu software é para aplicações de alta confiabilidade ou segurança crítica, então você realmente se preocupa com o OOT, especialmente o OOT “seguro”. Por que? Simples: os sistemas estão se tornando mais complexos, o software está fazendo mais desse gerenciamento de complexidade, e os horários estão apertando; enquanto não há uma única bala mágica, OOT fornece muitas respostas. E você não gostaria de ter um único livro que explicasse OOT, fornecesse um tutorial, tivesse exemplos decentes e enfatizasse os aspectos críticos de segurança? Impossível para um único livro fornecer tal? Recebemos essa pergunta muitas vezes durante os vários cursos de treinamento de desenvolvimento críticos em segurança da AFuzion. Nossos treinadores aprenderam a fornecer uma resposta consistente: entenda “DO-332”, a diretriz da comunidade de aviação para o OOT crítico de segurança e você terá muitas das respostas. Aqui está uma breve sinopse abaixo, e o whitepaper técnico completo de 12 páginas está disponível aqui para um download gratuito: Clique aqui para o Whitepaper Técnico OOT de 12 páginas grátis da AFuzion

DO-332, Suplemento de Tecnologia Orientada a Objetos e Técnicas Relacionadas ao DO-178C e DO-278A é uma diretriz de 150 páginas que rege o uso de OOT em software de aviação no ar e no solo. No entanto, uma vez que o verdadeiro OOT é relativamente novo para o software de aviação, (embora Ada ‘95 tem existado desde … 1995), os autores do DO-332 enfrentaram um grande obstáculo: como fornecer diretrizes significativas para pessoas geralmente desconhecidas com software orientado a objetos? A resposta foi habilmente tratada dentro do DO-332, mesclando “diretrizes” práticas com uma introdução ao OOT que estabeleceu uma base comum para terminologia, aplicação e certificação OOT.

Existem muitas maneiras de abordar o desenvolvimento de software; centenas de livros estão impressos com muitos aparentemente pregando sua própria “metodologia”. Mas como todas as muitas cores em um pavão provêm do vermelho-verde-azul básico, o desenvolvimento de software em sua maior (excessivamente) vantagem simplificada tem duas “cores primárias”: design estruturado funcional e design orientado a objetos. Ao contrário do pavão, com software essas “cores” não se misturam bem; muitos elementos de design de software são considerados “funcionais” ou “orientados a objetos”. O software funcional tradicional é projetado considerando então estruturar cada sequência de ações de computador uma de cada vez. Por outro lado, o software orientado a objetos é projetado primeiro articulando objetos e ações de software a serem executadas nesses objetos e, em seguida, integrando tais objetos/ações em grupos e eventos significativos. Sim, o design funcional pode ter alguns objetos. Sim, o design orientado a objetos usará alguns comportamentos estruturais sequenciais. Mas como algumas gotas de óleo podem flutuar sobre a água, que o óleo e a água dificilmente estão integrados; similarmente funcional e orientado a objetos, são duas abordagens distintas que, em suas formas puras, não se integram facilmente entre si.

Antes da publicação do DO-332, os desenvolvedores de software críticos à segurança tinham poucas regras para aplicar o OOT. Padrões de programação como MISRA C++ estavam disponíveis e bem; estes foram utilizados e ainda devem ser aplicados juntamente com uma ferramenta comercial de análise estática para higienizar e melhorar o código fonte C++. No entanto, faltavam orientações claras para o design e a verificação de OOT críticos à segurança; DO-332 tenta preencher esse vazio. No design funcional do software, o fluxo de controle é predestinado pelo desenvolvedor, assim, a sequência de decisões (“fluxo de controle” no DO-178C) é considerada juntamente com a função de dados de entrada e saída por função (“fluxo de dados” no DO-178C). Uma sequência estruturada típica é retratada abaixo:

No design do software orientado a objetos, os aspectos individuais de fluxo de dados e fluxo de controle são encapsulados através de objetos como descrito neste diagrama de classe OOT; note que os elementos de fluxo de dados/controle de baixo nível são menos visíveis do que no diagrama estruturado descrito anteriormente: (veja o diagrama completo no whitepaper OOT da AFuzion disponível aqui: Free Download AFuzion’s DO-332 OOT Whitepaper

Domínios críticos à segurança, incluindo a aviação, são avessos ao risco; novas tecnologias são consideradas suspeitas até que sua segurança seja comprovada. Em software crítico à segurança, determinismo e verificação são primordiais. Durante muitos anos, os tradicionalistas alegaram que o desenvolvimento de software funcional era mais determinístico do que o OOT: o sequenciamento de execução do software estruturado era facilmente determinado e repetível. E no nível da unidade (funções de software e coleções de funções dentro de um arquivo), o software estruturado funcional foi mais facilmente verificado: seções de código fonte poderiam ser rastreadas diretamente aos requisitos de software de baixo nível associados (LLR’s) e sequência testada por sequência. Assim, o design funcional de software permitiu facilmente determinismo e verificabilidade, ao mesmo tempo em que o fez de forma confiável por décadas. Com um histórico tão bem sucedido de confiabilidade, por que alguém desejaria o OOT com sua mudança radical de paradigma? Simples: a própria essência da evolução…

De acordo com o darwinismo, a evolução ocorre na natureza quando uma mudança genética é vista para fornecer vantagens para a sobrevivência. Da mesma forma para a tecnologia, a evolução ocorre quando uma mudança proporciona vantagem econômica, que é a sobrevivência comercial. A evolução do software do design funcional para o OOT ocorreu pela simples razão de que o OOT cada vez mais incorporava duas vantagens econômicas sobre o design funcional: 1) maior capacidade de gerenciar a complexidade do software crescente e 2) maior reutilização. As sementes da evolução do software de aviação brotaram assim.

Entender a necessidade do OOT é entender a necessidade do DO-332: o software de aviação, como todos os softwares, foi (e ainda é hoje) crescendo drasticamente em tamanho, complexidade e, portanto, custo. A segurança aprimorada significou o aumento da funcionalidade do software, o que significou aumento do tamanho e complexidade do software. O software estruturado funcional é bom, até mesmo vantajoso, quando a funcionalidade é simples. O poder da computação aumentou exponencialmente de acordo com a lei de Moore, permitindo que os desenvolvedores de aviação aproveitassem esse aumento da capacidade. Introdução OOT.

Na era do ferro da computação (há 50 a 20 anos), o software foi escrito manualmente concebendo a execução de instrução sequencial necessária para alcançar um objetivo. Quando o suporte de hardware próximo era necessário, a linguagem de montagem era favorecida para um controle mais direto do nível da CPU; de outra forma, linguagens de origem como FORTRAN, Ada ou C eram tipicamente usadas para programação científica. O software de aviação cresceu exponencialmente nos anos 70 e 80, o que significa que Ada e C predominaram como a linguagem de escolha. Melhorar a reutilizabilidade e o gerenciamento de complexidade foi cada vez mais importante para que os desenvolvedores inteligentes implantassem uma variedade de técnicas para esses objetivos: encapsulamento, abstração de hardware, invólucros e bibliotecas de construção de componentes de software com interfaces genéricas e robustas. Embora essas técnicas melhorem a reutilização e a gestão da complexidade, os setores comercial de consumo e financeiro foram muito além: eles repensaram toda a premissa da programação através da escrita de instruções sequenciais e, em vez disso, adotaram a programação orientada a objetos (OO) através de uma variedade de linguagens projetadas especialmente para o suporte ao OO. O mundo crítico à segurança seguiu lentamente, embora o OO colocasse desafios à verificação e, portanto, à certificação. Para entender por que a OO tinha tais desafios, é necessário primeiro entender OO.

Em vez de meramente conceber e escrever (“codificação”) instruções sequenciais para um programa de computador, os desenvolvedores de OO pensam em termos de Objetos. Um objeto contém dados e procedimentos encapsulados que são combinados e, portanto, representam uma entidade. Um objeto é uma estrutura de dados que contém dados. As instruções (“código”) são implementadas dentro de procedimentos chamados de “métodos”. O objeto tem interfaces que descrevem como ele interage dentro do programa. Em vez de pensar em termos de instruções individuais sequenciais, os desenvolvedores de OO executam a programação em um nível mais alto, definindo objetos e interações que consistem em grupos de instruções em vez de instruções sequenciais únicas. Os métodos de um objeto podem acessar e, possivelmente, atualizar dados dentro do objeto. Os objetos têm muitas formas como mostrado aqui (veja o whitepaper do AFuzion para figuras reais).

Objetos então podem tomar muitas formas diferentes, mas em cada uma dessas formas um objeto mantém os seguintes atributos:

  • É uma abstração de um conceito ou coisa do mundo real
  • Tem um limite claro
  • Tem uma identidade única
  • Sabe coisas sobre si mesmo
  • Pode realizar ações em si mesmo
  • Pode interagir com outros objetos

Como pessoas, profissões e até aeronaves, os objetos podem variar drasticamente em sua funcionalidade, habilidade e complexidade. No seu mais simplista, existem três tipos básicos de objetos como descrito abaixo:

Como pode ser visto no whitepaper do AFuzion no OOT, os objetos em si são capazes e interessantes. Mas por si só eles não são tão úteis. Considere um motor de aeronave: por si só ele também é capaz e interessante. No entanto, o motor se torna poderoso e útil quando combinado com uma estrutura de aeronaves, asas e sistemas de controle. Da mesma forma, um objeto torna-se poderoso e útil quando usado no contexto da Programação Orientada a Objetos (OOP). Os conceitos básicos do OOP são os recursos de design de software incorporados dentro da linguagem de programação, tipicamente C++ para a aviação e muitos dos sistemas críticos à segurança atuais. Esses aspectos são resumidos na figura abaixo (baixe o whitepaper do AFuzion para obter os detalhes completos).

Para obter informações sobre treinamento avançado do DO-178C e desenvolvimento de software para aplicações críticas à segurança, clique aqui:

http://afuzion.com/training/avionics-software-advanced-do-178c-training-class/

Artigo Original