sábado, 6 de setembro de 2014


1st International Seminar on Safety-critical Systems



Na semana de 02 a 04 de setembro de 2014 participei do Primeiro Seminário Internacional Sobre Segurança em Sistemas Críticos no Parque Tecnológico de São José dos Campos, o que envolveu os domínios de aviação, saúde, transporte, energia e afins. Durante o seminário criei algumas perspectivas sobre Verificação & Validação, Engenharia de Sistemas Baseados em Modelos (MBSE) e Segurança (reliability:safety). Uma vez que a imensa dificuldade em juntar os pontos já é uma barreira para o desenvolvimento das indústrias no Brasil, o objetivo desse artigo é contrastar métodos, técnicas e ferramentas entre as engenharias de software e a de sistemas que foram apresentadas no seminário. No final, cito referências e indico outros estudos. Boa leitura!


Primeiro dia

O primeiro dia foi dedicado a V&V com foco na disciplina de teste de sistemas, cujas técnicas e métodos são as mesmas de teste de software, inclusive indico a leitura das notas que escrevi alguns anos atrás para entender, brevemente, as técnicas e métodos. Se quiser se aprofundar, leia o excelente livro "Foundations of Software Testing" de Aditya P. Mathur. Infelizmente, não faz parte das referências básicas dos cursos que tenho visto no Brasil, embora seja o melhor livro que já li sobre o assunto até o momento.

Entre os desafios para construção de sistemas críticos na disciplina de teste, não encontrei muitas novidades sobre o que pesquisamos em engenharia de software nos últimos 47 anos, com exceção as restrições de normas idiomáticas para cada domínio de sistemas. Nesse sentido, duas normas foram bastante citadas no evento, a norma MISRA referente ao domínio de sistemas automotivos e a norma DO-178B/C referente aos sistemas aviônicos.

Na engenharia de software quando criamos uma maneira de codificar abrangendo definição de nomes, criação de métodos, classes e acessos, além de melhores práticas, chamamos de idioma da linguagem. Um ótimo livro sobre o idioma da linguagem Java é "Java 2 Performance and Idiom Guide: Guidelines for Java 2 performance, coding, and testing" do Craig Larman. Enquanto muitos desenvolvedores aprendem a programar com maturidade em uma linguagem com o mínimo de 5 anos, com o estudo de um idioma esse tempo pode ser reduzido em até 2. O problema é que muitas empresas, ainda aquelas que desenvolvem sistemas críticos, pouco sabem sobre como associar idiomas de uma linguagem em seu processo de desenvolvimento, tornando-se um dos primeiros desafios no tocante a V&V. Por isso a existência dos padrões MISRA e DO-178B/C, porém nada foi comentado a cerca dos design patterns, princípios, estilos e padrões adotados na engenharia de software. 

Já que pouco se sabe sobre idioma, como medir a qualidade do código? Embora existam diversas métricas para medir coesão, reuso, acoplamento e manutenibilidade dos sistemas, pelo que notei através das perguntas, as práticas de gerenciamento da dívida técnica ainda estão muito longe de serem utilizadas nos sistemas críticos. O fato de existir uma série de riscos a serem mitigados [que incorrem em perdas humanas], incluir essas preocupações não aumentaria a complexidade para um desenvolvedor de sistemas comuns, mas talvez para engenheiros de sistemas essa mudança seja radical, até pela forma densa que os sistemas são desenvolvidos. Continue lendo que eu explico lá na frente porque.


Segundo dia

No segundo dia, problemas relacionados aos custos, qualidade e comunicação foram evidenciados como outros desafios a serem enfrentados durante o desenvolvimento dos sistemas críticos. Uma das causas principais se dá pelo fato da inexistência de engenheiros de sistemas necessários, já que estes são substituídos por bacharéis ou mestres das linhas de sistemas de computação ou profissionais próximos. Nesse sentido, foi necessário criar abordagens para contornar barreiras de comunicação entre os profissionais, daí surge o paradigma de Engenharia de Sistemas Baseados em Modelos (MBSE). A Model-driven Architecture (MDA) é uma forma pragmática de aplicar a MBSE, embora ela tenha sido mencionada apenas em um único slide no evento [fiquei realmente frustrado, porque pesquiso MDA há 8 anos]. 

Por conta do foco dado a utilização de uma das ferramentas que patrocinou o evento, pouquíssimo foi mostrado sobre os benefícios da MDA, se tornando o ponto baixo do seminário na minha opinião. Em relação a MDA, sabe-se desde 2005 que o maior desafio está em gerar modelos corretos de acordo com as regras de negócio. O metamodelo MOF (Meta Object Facilit), que suporta os metamodelos da UML e SysML (linguagens utilizadas pela ferramenta), é muito limitado nesse sentido. Diante desse problema, vários pesquisadores tentaram criar extensões do MOF ou criar pontos específicos para adicionar formalismos e assim poder trabalhar com sistemas críticos adequadamente.

No Brasil, o trabalho mais citado na história do Simpósio Brasileiro de Componentes, Arquiteturas e Reutilização de Software (SBCARS) trata justamente sobre isso. O artigo “Separação e Validação de Regras de Negócios MDA Através deOntologias e Orientação à Aspectos” tem como objetivo principal construir modelos corretos do ponto de vista formal, gerar um modelo de regras de negócio separado e derivá-lo para uma linguagem de programação automaticamente. Desta forma, o trabalho demonstra um passo importante para criação de sistemas críticos utilizando MBSE por incluir V&V do ponto de vista formal, algo que não pode ser alcançado apenas com a UML e SysML. Outro ponto positivo do trabalho é que a abordagem também facilita a criação e manutenção de linhas de produtos de software tornando-as mais robustas, já que as regras de negócio é a variabilidade do domínio mais difícil de se gerenciar. Se você ainda duvida, pergunte-se por que empresas que mantém ERPs cobram uma fortuna para modificar regras de negócios: antes, durante e após a implantação desses sistemas?

Voltando ao segundo dia, o evento focou numa ferramenta que é considerada uma das mais desejadas pelos engenheiros de sistemas, porém não avança no principal problema da abordagem MBSE, que é melhorar a confiabilidade dos sistemas críticos. Apenas criar modelos com base na UML e SysML não é o bastante! Percebendo o diferencial entre essa ferramenta e as outras, comumente utilizadas para geração de modelos, há possibilidade de inserir um diagrama de blocos (SysML) ou de atividades (UML) com o objetivo de simular a troca de estados de componentes, porém nada muito distante que outras ferramentas como UPPAAL e SPIN fazem há décadas e com a vantagem de serem abertas, sem custo e promover o formalismo que não existe no MOF. Por fim, me senti extremamente desapontado pela MBSE e MDA não terem sido abordadas com a devida importância que a própria engenharia de sistemas as elevou nos últimos anos.

Outra palestra que também aconteceu no segundo dia deveria apresentar tópicos sobre o desenvolvimento de requisitos, porém não mencionou guias, standards, métodos ou técnicas, ficou muito aquém do título "Requirements Development". Achei realmente péssima, apenas abordou o modelo V. No Guide to the Software Engineering Body of Knowledge (SWEBOK), guia criado com colaboração de muitos especialistas em diversas linhas da computação e engenharia de sistemas (inclusive participei da revisão de alguns tópicos na última versão), é possível ver tudo que a palestra deveria nos fornecer sobre desenvolvimento de requisitos.

Outros desafios foram a rastreabilidade de requisitos e o tratamento de exceções. Alguns anos atrás a engenharia de software conseguiu contornar esses problemas com o uso de anotações. Aumentou a produtividade, permitiu associar idiomas e padrões, além de detectar e tratar exceções em tempo de execução com a utilização de frameworks de teste e da plataforma de uma linguagem de programação. No tocante ao tratamento de exceções de regras de negócio, a ferramenta "OWLtoAspectJ" permite gerar código automaticamente usando uma abordagem MDA. Se a média do tempo gasto para realizar a construção de testes pode chegar até 20% do esforço em um projeto, tudo isso poderia ser reduzido completamente com o aperfeiçoamento dessa ferramenta para o domínio de sistemas críticos.


Terceiro dia

Foi um dia bastante agradável. Logo percebe-se a importância que a segurança (realiability:safety) possui nos cenários de uso dos sistemas críticos de aviação e os problemas para utilização de abordagens ágeis: as normas. 

As normas de defesa e civil são abrangentes não só a arquitetura de sistemas de sistemas (SoS), mas adentram no seu cerne, as regras de negócio. No desenvolvimento de sistemas não-críticos não estamos acostumados a ter uma interferência tão direta no nosso domínio. Assim, em um processo padrão de SoS, constituído pelo gerenciamento de requisitos, análise e design, desenvolvimento e teste, é preciso incluir fatos para provar que o código implementa as regras de negócio impostas pelas normas.

A Alston apresentou um case no segundo dia para ser exato, mas foi tanta overdose da ferramenta de análise e design que só consegui lembrar no dia seguinte. Eles criaram um EAF (Enterprise Architecture Framework) e derivaram uma metodologia para criar novas arquiteturas de sistemas que permitissem utilizar idiomas, processos e ferramentas de acordo com o ciclo de vida dos sistemas. Ainda não conseguiram obter reuso e gestão das variabilidades, mas estão no caminho certo. A abordagem da Embraer foi específica para segurança, mas a estrutura de EAF está oculta, apenas emergiram um processo compartilhado para coleta de dados com fins de simulação e previsão de defeitos. Entretanto, logo vão descobrir que existe uma arquitetura corporativa que pode prover benefícios além da coleta automática de dados e o desenvolvimento de novos produtos com mais facilidade.

Toda parte de segurança é primordial para garantir o funcionamento correto dos sistemas críticos no domínio de aviação. Existe ainda muitas normas específicas para simulação de modelos, somando-se as “normais” do desenvolvimento. É preciso definir cada função do SoS incluindo um processo de V&V para cobrir todas as falhas previstas nos requisitos. A confiabilidade é tão alta, que o objetivo é evitar que um sistema destrua a imagem da empresa definitivamente por conta de um defeito catastrófico. Essa máxima se aplica -> “você é o que você faz” e não cabe o ditado: “casa de ferreiro espeto de pau” de forma alguma.

Entre as ferramentas possíveis, procuram-se as que possam facilitar simulações de falhas, como a Simulink, Rede de Petri, Cadeias de Markov e criação automática de árvores de falhas relacionadas com cada função do SoS. Lembrando que o desafio desse terceiro dia é unir mais uma vez as normas para certificar que o sistema é seguro, conforme autoridades europeias e/ou americanas. Nesse sentido, ficou constatado durante o evento que escolher um centro de certificação que não esteja alinhado ao seu arcabouço pode complicar ainda mais o processo de desenvolvimento do seu sistema. Assim, penso que seria mais fácil utilizar um EAF mais alinhado a autoridade, que tentar criar um próprio, a exemplo do DoDAF (Departmentof Defense Enterprise Architecture Framework) para área de defesa. 

Se você quiser saber qual EAF é mais adequado a sua realidade, procure a revista Mundo J edição de janeiro/fevereiro de 2012. Escrevi um roteiro com esse objetivo! Leia mais sobre o FACTO Framework de Arquitetura Corporativa aqui.

No tocante aos sistemas computacionais, as áreas de Engenharia de Software e Sistemas Distribuídos (construção de sistemas, confiabilidade e formalismo) estão um pouco distantes. Assim, é possível encontrar tópicos de pesquisas que a outra possui maturidade há anos, tornando os avanços apresentados nos últimos anos até mesmo insignificantes em uma determinada área na minha opinião. É muito raro alguém estudar grandes áreas para propor algo novo, a maioria fica centrada em sua área do doutorado, o que é natural. No mestrado e doutorado, aprofundamos conhecimento numa área, assim estudamos na vertical e top-down, mas os problemas dos sistemas críticos e complexos crescem na horizontal também, por isso é necessário unir conhecimentos maduros das outras áreas para evitar esforços desnecessários. 


Conclusão

Em face aos desafios constatados: (i) V&V com foco na disciplina de teste de sistemas, (ii) geração de modelos corretos, (iii) implantação de regras de negócios aderentes as normas de certificação, (iv) rastreabilidade de requisitos e (v) tratamento de exceções, há de fato poucos avanços na engenharia de sistema vistos no evento. Desde o início, foi percebido que uma das maiores dificuldades é a junção de diversas visões alinhadas às estratégias de negócio, processos de desenvolvimento e de gestão, além das competências pessoais e aderência às normas de certificação. Como se não bastasse tudo isso, é preciso gerenciar as variabilidades por domínio e produto, incluindo as perspectivas dos interessados no ciclo de desenvolvimento dos sistemas. Ao elevar esses desafios a um patamar de corporação, tornou-se possível pensar num sistema holístico, dinâmico e pragmático, como demonstrou o case da Alston. Nesse sentido, um EAF pode ser uma solução ainda mais robusta que a própria MBSE para construir sistemas críticos e complexos. Espero que todos tenham percebido isso!


Referências (leia cada uma delas)

DO 278 - http://www.adacore.com/gnatpro-safety-critical/atm/do-278-overview/

ARP 4761 -  http://standards.sae.org/arp4761/

ARP 5150/51 -  http://www-users.cs.york.ac.uk/~mark/projects/aja506_project.pdf

ARP 4754 - http://sunnyday.mit.edu/16.355/arp4754a.pdf 


The relationship between ARP 4761 and STPA  http://sunnyday.mit.edu/papers/ARP4761-Comparison-Report-final-1.pdf

Quantitative Measures for Software Independent Verification and Validation http://ston.jsc.nasa.gov/collections/trs/_techrep/TP3634.pdf

Normas para cobertura estrutural

Confiabilidade de Requisitos 
ISO/IEC 17000-2005 - http://www.google.com.br/

Linha de produtos de Software e Engenharia de Sistemas
ISO/IEC 26550 - http://www.iso.org/

Uma taxonomia de falhas para sistemas distribuídos em 2004 pode ser muito útil para criar uma perspectiva de confiabilidade e assim atender as normas durante o desenvolvimento de sistemas críticos https://homes.cs.washington.edu/~ransford/srg/papers/avizienis--dependable-secure.pdf

Como organizar a perspectiva de confiabilidade através do desenvolvimento de sistemas de forma pragmática "Tratamento de Falhas Residuais Durante o Design de Sistemas de Software" http://jaguaracisilva.blogspot.com.br/2012/09/tratamento-de-falhas-residuais-durante.html

Para organizar o seu sistema de monitoramento da qualidade para atender a perspectiva de confiabilidade, poderia criar o seu próprio modelo de qualidade para V&V de sistemas críticos usando ISO/IEC 25000 (Square)  http://iso25000.com/index.php/en/iso-25000-standards

Inscreva-se

Creative Commons 3.0. Tecnologia do Blogger.

Teste a Velocidade da Internet

Siga-me

Curta