D O MODELO V PARA Y: C ICLO DE DESENVOLVIMENTO PARA SISTEMAS CRÍTICOS Farley Millano

Apresentação em tema: "D O MODELO V PARA Y: C ICLO DE DESENVOLVIMENTO PARA SISTEMAS CRÍTICOS Farley Millano"— Transcrição da apresentação:

1 D O MODELO V PARA Y: C ICLO DE DESENVOLVIMENTO PARA SISTEMAS CRÍTICOS Farley Millano (fmmf@cin.ufpe.br)

2 MOTIVAÇÃO Complexidade crescente em sistemas críticos de software Tempo de desenvolvimento crescente vs. time-to- market Atividades de verificação são EXTREMAMENTE custosas Tempo $$$ A qualidade precisa sempre ser melhorada

3 MOTIVACÃO... PRINCIPAL! Roger Pratt. Flight Control Systems: Practical Issues in Design and Implementation. 2000

4 A GENDA História e tendências Model-based development Aplicação na Airbus Padrões, qualificação e certificação SCADE Parceria Cin - Embraer Proposta de trabalho – CNL + SCR Conclusão

5 H ISTÓRIA 70s e 80s Codificação manual: código de máquina e Assembly Programação estruturada: C, Ada (Subsets para aplicações críticas, eg. SPARKAda) 90s e 00s Object-Oriented Programming e.g. FAA OOT Initiative 10s Model-Based Software Development e.g. SCADE

6 TENDÊNCIA

7 B ENEFÍCIOS O modelo é o único ponto de referência no projeto Código fonte é gerado automaticamente de um gerador qualificado Correto e atualizado por construção Documentação também é gerada automaticamente Simulações em cima do modelo são possíveis Bugs são detectados através de provas formais Também usado para provar propriedades de safety

8 V- MODEL : CICLO DE VIDA High level design Detailed design Contrato Codificação Requisitos produto Teste de sistema Teste de integração Teste unitário Teste de aceitação Revisão / Teste Requisitos usuário Garantia Gerência do projeto Desenvolvimento de software Garantia da qualidade

9 V PARA Y-M ODEL Req do Cliente Req do SW Design Codificação Teste de Unidade Teste de Componente Teste de Integração Teste de Aceitação Fases do Desenvolvimento Volume de Defeitos

10 A IRBUS -20% -25% -50% Custo 0% Codificação Manual Uso de gerador de código regular Uso de gerador de código qualificado como verificador Uso de tecnologia de prova Uso do gerador qualificado como ferramenta de desenvolvimento -60%

11 A IRBUS - DADOS Desenvolvimento e teste em média de 10.000 linhas de código (KLOC) do software da DO-178 level B 16 homens-anos Custo de um bug minor é entre $100K - $500K para aviões em vôo. O mesmo para major é $1M - $500M! A Airbus decidiu no início dos anos 80 inserir código gerado automaticamente

12 A IRBUS - DADOS Fonte: Esterel Technologies

13 C ASE – A340/600 FCSC (Flight Control Secondary Computer) 70% do código foi gerado automaticamente Redução de 50% no custo de desenvolvimento O ciclo do controle de alteração sofreu uma redução de fator 3 do tempo

14 C ASE – A340/600 Fonte: Esterel Technologies

15 PADRÕES E CERTIFICAÇÕES PARA SISTEMAS CRÍTICOS RTCA DO-178B (Civil Aircraft), 1980 and 1992 ARP 4754 IEC 61508 Functional Safety of Electrical / Electronic /Programmable Electronic Safety- Related Systems

16 NÍVEIS DE CLASSIFICAÇÃO Qualifiable: Ferramenta desenvolvida de forma que ela está pronta para ser “qualificada” em projetos específicos Qualified: Classificação por projeto, o nível de criticalidade da ferramenta deve ser equivalente ao do sistema de software Certified: Reconhecimento legal por autoridades especializadas que o produto é compatível com os requisitos

17 REQUISITOS DE CLASSIFICAÇÃO Requisitos de classificação para Gerador Automático de Código (ACG) com respeito a DO-178B: ACG defined as: “Tool whose output is part of the airborne software and thus can introduce errors ” DO-178B, section 12.2.1: “ If a software tool is to be qualified, the software development processes for the tool should satisfy the same objectives as the software development processes of airborne software. The software level assigned to the tool should be the same as that for the airborne software it produces.”

18 S CADE SCADE (Safety Critical Application Development Environment) Desenvolvido em1997 pela Airbus Desde 2001, desenvolvida e distribuída por Esterel Technolgies Padrão de-facto nas indústrias aeroespaciais e energia nuclear Aplicação “core” para o EU-SafeAir (ASDE: Avionics Systems Development Environment) Project

19 S CADE - PROCESSO

20 S CADE – C RUISE CONTROL

21 S CADE - IDE Diagrama de blocos Máquinas de estado, concorrência e hierarquia

22 S CADE - S ETTINGS

23 S CADE - FEATURES Editor gráfico e textual Simulador Prova formal do design Gerador de código(DO-178B, EN 50128 and IEC 61508 certified) Cobertura de teste de modelo Gateways : Simulink, DOORS, Altia, UML/SysML, etc.

24 H ISTÓRICO P ARCERIA CIN - E MBRAER Início: 2007 Métodos formais tem sido bastante discutido e desenvolvido para sistemas aviônicos Embraer: mapeamento de especialistas no Brasil Projeto piloto: 2007 - Joabe Modelagem, model-checking e análise do Fly-by-wire Nova iteração: 2008 – Adriano e Farley Estudo do processo geral de desenvolvimento Análise de pontos de colaboração Modelagem + segurança Requisitos (CNL e SCR) + Testes

25 E MBRAER - P ROBLEMAS Setup de teste muito longo (4 meses) Avaliação automática de resultado de testes Pouca automação em fases iniciais (requisitos), apesar de estar em um domínio fechado de aplicação Requisitos possivelmente reusáveis Análise e validação baseada em checklists Alinhamento de requisitos e modelagem de segurança Consideração de fatores, como: tempo de manutenção x tempo de vôo

26 V PARA Y-M ODEL [ RELEMBRANDO ] Req do Cliente Req do SW Design Codificação Teste de Unidade Teste de Componente Teste de Integração Teste de Aceitação Fases do Desenvolvimento Volume de Defeitos

27 P ARCERIA CIN - E MBRAER Requisitos Teste de Unidade Teste de Componentes Teste de Integração CNL Funcionais Design Testes Codificação Execução Avaliação Análise (Dinâmicos) Geração automática SCR

28 CNL Controlled Natural Language Escrita de requisitos de acordo com “case frame” de cada verbo Agent, Goal, Location, Instrument, etc. A sintaxe é bem estruturada Redução de tempo na fase de validação de requisitos Identificação de reuso Eliminação de ambigüidade A partir disso é definido o mapeamento para outras representações Apesar de ser controlada é muito próxima da forma como requisitos é escrito usualmente

29 SCR Software Cost Reduction Fundamentado no sistema A-7 Operational Flight Program David Parnas e pesquisadores do U.S. Naval Research Laboratory (NRL) em 1978 Notação tabular formal de requisitos Comportamento definido por cláusulas condicionais Representação usada em larga escala para sistemas críticos Ótimo suporte ferramental Provador de teorema Análise de inconsistência Gerador de invariante...... CASOS DE TESTE! Crítica: Representação não muito usual para usuários comuns

30 SCR - E XEMPLO “Se Pressure é TooLow e WaterPres se eleva para ou acima de Low, então Pressure muda para Permited”

31 SCR - E XEMPLO “Se Pressure é High ou Permitted, ou se Pressure é TooLow e Overriden é true, então SafetyInjection é Off; se Pressure é TooLow e Overriden é false, então Safety Injection é On ”

32 SCR - T OOLSET

33 M APEAMENTO DE SCR PARA T-V EC T-Vec: linguagem de modelagem de testes São definidas regras de mapeamento entre ambas as representações, tipos de dados, relacionamentos e funções Ex: Isso já é feito automaticamente por ferramentas Definição de variáveis T-VEC Variável de entrada Variável de saída ConstanteTipo SCR Variável de entrada, Termo e Classe de Modo Variável de saída, Termos Constante Tipo

34 P ROCESSO SCR PARA T-V EC

35 P ASSOS Desenvolvimento da especificação em SCR descrevendo o comportamento do sistema. Tradução das especificações em SCR para especificações de teste em T-VEC Gerar vetores de teste para especificações SCR traduzidas e realizar análise de cobertura Desenvolver esquemas de drivers de testes – algoritmo para condução dos testes – e mapeamento de objetos para o ambiente de teste – de representação no modelo para interfaces no sistema sob teste. Carregar drivers de teste, executar testes e gerar o relatório de testes. Passos feitos automaticamente

36 O BJETIVOS DO TRABALHO Mapeamento entre CNL e SCR Implicitamente a gente está chegando em T-Vec Usar a “naturalidade” [ainda que controlada] da CNL para expressar requisitos Ao mesmo tempo, aproveitar o poderio do SCR e suas ferramentas Implementaçao do modelo Y: Realizar “Teste de requisitos” Antecipação de problemas = diminuição de custos Manutenção de requisitos legados Redução do tempo nas fases de análise e validação dos requisitos

37 S TATUS DO TRABALHO Interação quinzenal com Embraer Mapeamento do processo de Engenharia de Requisitos Análise de ferramenta produzida pela Embraer Catalogação dos principais termos verbos, atores, temas, locação, instrumentos... Identificação de ponto de integração no processo

38 CONCLUSÃO O modelo Y é um conjunto de evoluções Arquitetura, requisitos, geração de código A European Aerospace Industry é pioneiro na aplicação da metodologia De facto na Airbus Ainda carece de um estudo para ampliação de domínios O modelo Y reduz o time-to-market e aumenta confiabilidade dos produtos É uma mudança de paradigma muito grande Ferramentas são muito caras