BR102016018127A2 - método para projeto com base em modelo de software de segurança crítica - Google Patents

método para projeto com base em modelo de software de segurança crítica Download PDF

Info

Publication number
BR102016018127A2
BR102016018127A2 BR102016018127A BR102016018127A BR102016018127A2 BR 102016018127 A2 BR102016018127 A2 BR 102016018127A2 BR 102016018127 A BR102016018127 A BR 102016018127A BR 102016018127 A BR102016018127 A BR 102016018127A BR 102016018127 A2 BR102016018127 A2 BR 102016018127A2
Authority
BR
Brazil
Prior art keywords
model
software
test cases
requirements
design
Prior art date
Application number
BR102016018127A
Other languages
English (en)
Inventor
Walsch Alexander
Walter Crapo Andrew
Reed Sykes Gregory
Yu Han
Yan Siu Kit
Parolini Luca
Li Meng
Richard Durling Michael
Manolios Panagiotis
Alan Stacey Scott
Lee Johnson Timothy
Original Assignee
Gen Electric
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Gen Electric filed Critical Gen Electric
Publication of BR102016018127A2 publication Critical patent/BR102016018127A2/pt

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3604—Software analysis for verifying properties of programs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G06F8/35—Creation or generation of source code model driven
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3604—Software analysis for verifying properties of programs
    • G06F11/3608—Software analysis for verifying properties of programs using formal methods, e.g. model checking, abstract interpretation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3668—Software testing
    • G06F11/3672—Test management
    • G06F11/3676—Test management for coverage analysis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3668—Software testing
    • G06F11/3672—Test management
    • G06F11/3684—Test management for test design, e.g. generating new test cases
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F40/00—Handling natural language data
    • G06F40/20—Natural language analysis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/10—Requirements analysis; Specification techniques
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/20—Software design
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/41—Compilation
    • G06F8/42—Syntactic analysis

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • General Health & Medical Sciences (AREA)
  • Health & Medical Sciences (AREA)
  • Computational Linguistics (AREA)
  • Audiology, Speech & Language Pathology (AREA)
  • Artificial Intelligence (AREA)
  • Stored Programmes (AREA)
  • Debugging And Monitoring (AREA)

Abstract

a presente invenção refere-se a um método para projeto com base em modelo de software de segurança crítica. o método inclui receber as exigências de software de linguagem natural, desenvolver um modelo de especificação implantando-se a modelagem semântica ou a modelagem gráfica, aplicar a análise de exigências formal ao modelo de especificação, autogerar os casos de teste de robustez e com base em exigências a partir do modelo de especificação, desenvolver um modelo de projeto com base no modelo de especificação, aplicar os casos de teste ao modelo de projeto, autogerar o código-fonte com uso do modelo de projeto, verificar o código-fonte com uso tanto dos casos de teste quanto da tecnologia de análise de estatística e compilar o código de objeto executável a partir do código-fonte verificado. se um resultado da análise da especificação de software ou modelos de projeto não for satisfatório, então, ajustar o modelo de projeto ou de especificação para corrigir qualquer inconsistência e repetir a aplicativo da análise e dos casos de teste. um sistema para implantar o projeto com base em modelo e um meio legível por computador não transitório são revelados.

Description

“MÉTODO PARA PROJETO COM BASE EM MODELO DE SOFTWARE DE SEGURANÇA CRÍTICA” Antecedentes [001] A propagação de equipamento controlado por microprocessador levou a dispositivos com capacidade ainda maior, mas deposita mais confiança na qualidade do software que controla esses sistemas embutidos. Muitas peças potencialmente perigosas do equipamento são controladas por software embutido (por exemplo, carros, trens, aeronaves, refinarias de óleo, usinas de processamento de produtos químicos, usinas de energia nuclear e dispositivos médicos, etc.). As abordagens convencionais para a verificação da correção de código de aplicativo operacional para esses dispositivos e sistemas são difíceis e ineficientes.
[002] O desenvolvimento de sistemas de software de segurança crítica aborda o aumento no tamanho e na complexidade desses sistemas e respeita a necessidade de manter as operações de segurança crítica. Há uma gama de métodos de engenharia de software, ferramentas e estruturas para desenvolver sistemas críticos complexos. Por exemplo, um método é a aplicação de técnicas de engenharia direcionada por modelo ao desenvolvimento de sistemas de segurança crítica.
[003] As abordagens convencionais podem incluir o uso de ferramentas de ambiente de projeto integrado (IDE) comercialmente disponíveis para realizar a modelagem de especificação de software, validação/ verificação e geração e execução de caso de teste. Tipicamente, essas ferramentas usam métodos rigorosos para automatizar ou semiautomatizar uma porção das etapas de projeto detalhadas, enquanto reduzem as exigências de entrada de dados para economizar tempo com as etapas restantes.
Breve Descrição das Figuras [004] A Figura 1 retrata um sistema para projeto com base em modelo de software de segurança crítica, de acordo com as realizações;
[005] A Figura 2 retrata um fluxograma de um processo para projeto com base em modelo de software de segurança crítica, de acordo com as realizações; e [006] A Figura 3 retrata um fluxograma para um processo de desenvolvimento com base em modelo, de acordo com as realizações.
Descrição [007] De acordo com as realizações, os sistemas e os métodos fornecem um processo de projeto automatizado com base em modelo para o desenvolvimento e a geração de teste de software de segurança crítica. Os sistemas e os métodos de concretização empregam uma ontologia de domínio específico e métodos de verificação formais para melhorar e estender as exigências de nível superior. Esses sistemas e métodos utilizam um modelo de especificação verificável (logo, o nome, "com base em modelo") como o fundamento de testes com base em exigências com geração automática antes de o software ser escrito. De acordo com as realizações, os testes com base em exigências são gerados a partir do modelo de especificação. Um modelo de projeto é usado para desenvolver o software. O rigor e a automação dessas etapas resultam no esforço de teste reduzido e projeto de software melhorado, na economia de tempo e custo para um desenvolvedor de software de segurança crítica.
[008] Incorporando-se os métodos formais e os modelos lógicos nos processos de concretização, os erros nas exigências de especificação podem ser identificados e as exigências podem ser verificadas para consistência e conclusão. Mediante a identificação de erros, as exigências podem ser reparadas iterativamente, se necessário, até que os mesmos sejam logicamente concluídos e consistentes quando testados novamente. As ontologias, as malhas semânticas e a análise de cobertura fornecem, todas, informações explícitas para estender as exigências que não estão concluídas.
[009] Os sistemas e os métodos de concretização podem incorporar “casos seguros” às exigências e etapas de verificação correspondentes (por exemplo, projeto com base em modelo). As relações temporais complexas (por exemplo, exigências de simultaneidade e/ou capacidades) também podem ser representadas.
[010] Uma vez que a especificação de exigências de software é concluída e consistente, os modelos de projeto e os testes de verificação/validação subsequentes podem ser gerados para a realização de teste de código-fonte. O código-fonte pode ser visto como uma representação mais detalhada do projeto especificado, que resulta no código executável e/ou objeto que concretiza as mesmas exigências de projeto.
[011] As abordagens de concretização resultam em uma redução de erros detectados durante as atividades de verificação/validação. Os sistemas e os métodos de concretização automatizam esses processos que resultam em um processo de validação/verificação/projeto mais rigoroso, o que fornece uma redução no trabalho associado ao desenvolvimento e no custo de tempo fornecendo-se uma precisão mais alta no atendimento às exigências de projeto e uma velocidade maior na correção e realização de teste, em comparação à geração de código auxiliada por ferramenta manual, convencional.
[012] Os sistemas e os métodos com base em modelo de concretização substituem as declarações lógicas formais, matematicamente rigorosas, que definem as exigências de geração de teste, projeto e operação para as declarações com base em linguagem natural, fornecendo, assim, uma oportunidade, durante o processo de projeto inicial, para melhorar a qualidade, o rigor, a consistência e o escopo de exigências.
[013] A Figura 1 retrata o sistema 100 para o desenvolvimento de software de computador de segurança crítica, de acordo com uma realização. O sistema 100 pode incluir um computador (um único computador 110 que opera localmente, ou vários computadores 112, 114, 11N ligados juntamente por rede de comunicação eletrônica 120 (por exemplo, a Internet)), um banco de dados associado 130 que pode incluir as especificidades do software de segurança crítica — por exemplo, as exigências de sistema atribuídas ao software (SRATS) 132, um modelo de especificação de software 133, um modelo de projeto 134, um código-fonte autogerado 136, um código de objeto executável 138. O sistema 100 também pode incluir o banco de dados 140 que pode incluir as malhas semânticas 142, as ontologias 144, os casos de teste com base em exigência 146 e os casos de teste de cobertura de modelo autogerados 148. Embora o banco de dados 130 e o banco de dados 140 sejam retratados como dois bancos de dados, em algumas implantações, um banco de dados pode incluir todo o armazenamento; em outras implantações, mais de dois bancos de dados podem ser incluídos no sistema 100.
[014] De acordo com uma implantação, um único computador 110 pode incluir unidades de estrutura configuradas para realizar ações que implantam o projeto de software de segurança crítica com base em modo. Essas unidades podem incluir a unidade de modelagem semântica 150, a unidade de modelagem gráfica 152, a unidade de comprovação de teorema automatizada (ATP) 154, a unidade de geração de procedimento e de caso de teste automatizada (ATCPG) 156 e a unidade de geração de código automatizada 158. Em outras implantações, essas unidades podem ser distribuídas dentre os vários computadores ligados juntamente pela rede de comunicação eletrônica.
[015] A Figura 2 retrata um fluxograma de processo 200 para projeto com base em modelo de software de segurança crítica, de acordo com as realizações. O processo 200 analisa as SRATS de linguagem natural, desenvolve um modelo de especificação que, após a verificação e aceitação, é o fundamento para um modelo de projeto. O termo “modelo de projeto” (conforme usado no presente documento) é um modelo conceituai, tal como um modelo de objeto ou modelo de Linguagem de Modelagem Unificada (UML). Um modelo de projeto pode retratar as entidades e as transformações funcionais a serem realizadas pelo software de aplicativo.
[016] A partir do modelo de projeto, o primeiro código-fonte pode ser autogerado pelo processo 200 e, então, o código de objeto executável (EOC) pode ser gerado também. O processo 200 pode verificar o projeto, o código-fonte e o EOC. O EOC que resulta desse processo com base em exigências pode ser subsequentemente submetido aos métodos de realização de teste com base em EOC, que podem fornecer um retorno adicional.
[017] O modelo de especificação é capturado (etapa 205). A captura pode incluir a validação das SRATS de exigência de sistema de linguagem natural, textual, fornecidas ao sistema. A unidade de modelagem semântica 150 e/ou a unidade de modelagem gráfica 152 implanta(m) técnicas de modelagem gráfica e semântica para desenvolver um modelo de especificação a partir das SRATS. O modelo de especificação é implantado em uma linguagem natural estruturada que inclui um modelo semântico e pode ser visto ou editado em uma forma gráfica.
[018] A análise de exigência formal no modelo de especificação é realizada (etapa 210). O modelo de especificação pode ser analisado e verificado para a correção e consistência pela unidade de ATP 154, que implanta as técnicas de comprovação de teorema automatizadas. Os casos de teste do modelo de especificação são autogerados (etapa 215) pela unidade de ATCPG 156. De acordo com as realizações, o sistema pode empregar a ATCPG para autogerar os casos de teste para as exigências do próprio modelo de projeto. Em outras implantações, os casos de teste autogerados podem ser automaticamente gerados pelo sistema 100, com uso de verificação de modelo ou outra tecnologia de análise formal. O processo 200 pode retornar à etapa 205 para capturar adicionalmente o modelo de especificação e a análise de exigência, e/ou os casos de teste gerados deve(m) indicar que o modelo não é tão robusto quanto é necessário (isto é, que o modelo de especificação de software carece da consistência, da correção e/ou da conclusão exigida).
[019] Após a análise de exigência indicar que as exigências são concluídas e autoconsistentes, o modelo de especificação é o fundamento para o desenvolvimento de um modelo de projeto de software (etapa 220). Os casos de teste são gerados a partir do modelo de especificação e aplicados no modelo de projeto. Após os casos de teste serem aplicados ao modelo de projeto, a cobertura de modelo é analisada, etapa 225, com base no desempenho da mesma. Quaisquer defeitos ou inconsistências podem ser corrigidos, então, o modelo de projeto pode ser verificado (etapa 230) repetindo-se os cenários de caso de teste.
[020] O modelo de projeto verificado é usado pela unidade de geração de código automatizada 158 para autogerar (etapa 235) o código-fonte para o software de segurança crítica. O sistema 100, então, verifica (etapa 240) o código-fonte com uso de tecnologia de análise de estatística. O código de objeto executável é compilado (etapa 245) a partir do código-fonte verificado.
[021] A Figura 3 retrata um fluxograma para o processo de desenvolvimento com base em modelo 300, de acordo com as realizações. O sistema 100 para o desenvolvimento de software de computador de segurança crítica pode incluir os aplicativos implantados por computador 315, 320, 335, 340, 350, 360, 370 que recebem as informações de projeto a partir dos estágios 305, 310, 325, 330, 35, 355, 365 de processo de desenvolvimento com base em modelo 300. Em algumas modalidades, as informações de projeto recebidas podem ser complementadas com comandos adicionais e/ou instruções a partir de usuários humanos do sistema 100. Com base nas informações de projeto recebidas, conforme processado pelos aplicativos implantados por computador de sistema 100, o processo 300 pode produzir novos resultados — por exemplo: a confirmação de conclusão, os modelos de projeto, os novos testes de software e/ ou os defeitos de identificação de mensagem que especificam uma deficiência ou uma não conclusão dos dados de projeto para um estágio particular do processo de projeto.
[022] Se uma mensagem de identificação de defeito for produzida, então, o processo 300 retorna para os dados da etapa precedente (indicados por uma seta de duas vias que conecta várias etapas de processo dentro do processo 300). O defeito pode ser corrigido por um usuário humano, de acordo com uma recomendação fornecida pelo processo implantado por computador 300.
[023] Os dados de SRATS iniciais fornecidos ao processo 300 (etapa 305) incluem documentos de linguagem natural. O sistema 100 para o desenvolvimento de software de computador de segurança crítica gera automaticamente o software e gera automaticamente os casos de teste, bem como outra documentação ou informações de diagnóstico produzida(s) em estágios iniciais. Esses software, casos de teste, outra documentação e informações de diagnóstico são baseados nas SRATS fornecidas. O processo 300, conforme implantado pelo sistema 100 melhora o projeto de software de segurança crítica com uma redução de interação manual no processo de projeto. Para alcançar o desenvolvimento automatizado, de acordo com as realizações, o processo 300 inclui a validação com base em modelo de cliente de aplicativos implantados por computador (etapa 315), a análise de exigências formal (etapa 320), a verificação de projeto formal (etapa 335), a análise de cobertura de modelo (etapa 340), a verificação de modelo de projeto com base em teste (etapa 350), a verificação de código formal (etapa 360), a verificação de EOC com base em teste (etapa 370).
[024] O processo 300 começa com a recepção (etapa 305) de SRATS de documentos de linguagem natural textual derivadas de exigências de sistema de nível mais alto que incluem tanto as capacidades de hardware quanto as de software. A partir das SRATS, um Modelo de Especificação é desenvolvido (etapa 310) com uso de uma combinação de tecnologias de modelagem semântica e de modelagem gráfica. De acordo com as realizações, o sistema 100 que implanta o processo 300 eliminou a necessidade de capturar as Exigências de Alto Nível (HLRs) como texto. De acordo com as realizações, as HLRs convencionais são substituídas por um Modelo de Especificação legível por máquina e por humano.
[025] O Modelo de Especificação é validado (etapa 315). A validação pode ser feita com o auxílio de representações analíticas (por exemplo, as ontologias e as malhas semânticas) das exigências apresentadas a um usuário. O Modelo de Especificação é formalmente analisado e verificado (etapa 320) para a correção e consistência com uso de aplicativos de ATP. Essa etapa pode identificar os erros nas exigências antecipadamente no processo e reduz significativamente o retrabalho de ciclo tardio.
[026] Há um ciclo de retorno a partir da análise de exigências 320 para a captura do modelo de especificação 310. Esse ciclo de retorno fornece retorno em tempo real para alertar um engenheiro para um erro.
[027] Após a validação e a análise de exigência formal, o Modelo de Especificação passa como uma entrada para criar (etapa 330) um Modelo de Projeto. O modelo de projeto é formalmente verificado com uso de verificação de modelo (etapa 335). O Modelo de Especificação também é usado como uma entrada para o Processo de Geração de Caso de Teste Automatizado com base em Exigências (etapa 325). Os procedimentos e os casos de teste são automaticamente gerados (por exemplo, com uso de tecnologia de verificação de modelo). Os casos de teste são, então, aplicados (etapa 350) ao Modelo de Projeto e analisados para a funcionalidade correta.
[028] Há outro ciclo de retorno a partir da função de geração de caso de teste com base em exigências 325 para o modelo de especificação 310, a fim de indicar um indicador de complexidade de verificação que é proporcional à quantidade de casos de teste exigida para verificar o modelo de especificação. O engenheiro de captura de exigências pode usar essas informações para simplificar o modelo de especificação, a fim de diminuir o custo/complexidade de verificação. De acordo com as implantações, a ferramenta de captura de exigências também pode fornecer as opções sugeridas para capturar as mesmas informações em uma gramática que seria mais fácil de verificar (menos casos de teste).
[029] Quando os erros são detectados, o modelo de projeto é corrigido. Os defeitos e as inconsistências podem ser detectados nos casos em que uma sequência de etapas é realizada ou em que a ordem das etapas simultâneas não pode ser prevista: nesses casos, as correções de modelo de projeto podem ser feitas retrocedendo-se através das sequências, ou reforçando-se a ordenação temporal das etapas, de outro modo, não ordenadas. Posteriormente, os casos de teste são aplicados ao Modelo de Projeto e analisados para a cobertura de modelo (etapa 340). Essa etapa pode identificar lacunas na cobertura com base em (a) erros nos casos de teste com base em exigências, no modelo de especificação e/ou no modelo de projeto (por exemplo, funcionalidade não direcionada, código inoperante, etc.); ou (b) exigências derivadas. No caso de exigências derivadas, os casos de teste são automaticamente gerados (etapa 345) para satisfazer a cobertura de modelo.
[030] Uma ferramenta de geração de teste automatizada pode ser usada para ajudar um engenheiro a identificar o código não alcançável e para identificar um vetor de teste que irá executar a seção específica do modelo. Uma ferramenta de autogeração de código qualificada é usada para criar (etapa 355) o código-fonte a partir do modelo de projeto. O código-fonte é formalmente analisado (etapa 360) com uso de tecnologia de análise de estatística. O código-fonte é compilado (etapa 365) para o EOC. A verificação de EOC com base em teste é realizada (etapa 370) reaplicando-se o conjunto de teste desenvolvido anteriormente no processo. Uma vez que a verificação é realizada, o EOC compilado pode, então, ser submetido à unidade tradicional, ao subsistema e à realização de teste de sistema.
[031] Os sistemas e os métodos, de acordo com as realizações, aplicam técnicas de modelagem lógica e matemática rigorosas ao problema de verificação de consistência, de correção e/ou de conclusão de exigências de software, antes da geração de código. De acordo com as implantações, uma coleção de ferramentas pode cobrir todos os estágios de geração de software, análise e projeto preliminar. A pré-verificação torna prático o uso de geração de código automática e o uso de retorno no processo de projeto. Os sistemas e os processos de concretização podem detectar erros durante os processos de projeto preliminares e conceituais. A correção desses erros detectados pode se estender, melhorar, corrigir e/ou concluir as informações de projeto, antes de o código ser gerado.
[032] De acordo com algumas realizações, um aplicativo de programa de computador armazenado em memória não volátil ou meio legível por computador (por exemplo, memória de registro, cache de processador, memória de acesso aleatório, memória apenas de leitura, memória apenas de leitura de disco compacto, disco rígido, memória flash, meios magnéticos, etc.) pode incluir as instruções executáveis ou códigos que, quando executados, podem instruir e/ou fazer com que um controlador ou processador realize os métodos discutidos no presente documento, tal como um método para projeto com base em modelo de software de segurança crítica, conforme descrito acima.
[033] O meio legível por computador pode ser meios legíveis por computador não transitórios que incluem todas as formas e tipos de memória e todos os meios legíveis por computador, exceto para um sinal de propagação transitório. Em uma implantação, a memória não volátil ou o meio legível por computador pode ser uma memória externa.
[034] Embora os métodos e hardware específicos tenham sido descritos no presente documento, deve-se observar que qualquer quantidade de outras configurações pode ser fornecida, de acordo com as realizações da invenção. Assim, embora tenham sido mostrados, descritos e apontados os recursos inovadores fundamentais da invenção, será compreendido que várias omissões, substituições e mudanças na forma e nos detalhes das realizações ilustradas, e na operação das mesmas, podem ser feitas por aqueles versados na técnica, sem que se afaste do espírito e do escopo da invenção. As substituições de elementos de uma realização para outra também são totalmente contempladas e pretendidas. A invenção é definida somente em relação às reivindicações anexas à mesma e aos equivalentes das citações no presente documento.
Lista de Componentes 100 Sistema de desenvolvimento de software de computador de segurança crítica 110 Computador 112 Computador 114 Computador 11N Computador 120 Rede de comunicação eletrônica 130 Banco de dados 132 Exigências de sistema atribuídas ao software 133 Modelo de especificação de software 134 Modelo de projeto 136 Código-fonte autogerado 138 Código de objeto executável 140 Banco de dados 142 Malhas semânticas 144 Ontologias 146 Casos de teste com base em exigência 148 Casos de teste de cobertura de modelo autogerados 150 Unidade de modelagem semântica 152 Unidade de modelagem gráfica 154 Unidade de comprovação de teorema automatizada 156 Unidade de geração de procedimento e caso de teste automatizada 158 Unidade de geração de código automatizada Reivindicações

Claims (9)

1. MÉTODO PARA PROJETO COM BASE EM MODELO DE SOFTWARE DE SEGURANÇA CRÍTICA, sendo que o método é caracterizado pelo fato de que compreende: receber exigências de software de linguagem natural 132; desenvolver um modelo de especificação de software 133 em uma linguagem natural estruturada implantando-se pelo menos uma dentre modelagem semântica 150 e modelagem gráfica 152 das exigências de software de linguagem natural; aplicar análise de exigência formal do modelo de especificação de software; gerar automaticamente os casos de teste de robustez e com base em exigências, a partir do modelo de especificação de software; desenvolver um modelo de projeto de software com base no modelo de especificação; aplicar os casos de teste de robustez e com base em exigências gerados automaticamente ao modelo de projeto de software; conduzir a análise formal do modelo de projeto de software; autogerar código-fonte 136 com uso do modelo de projeto de software; verificar a cobertura e o comportamento do código-fonte aplicando-se os casos de teste gerados automaticamente 148 e a tecnologia de análise de estatística; compilar o código de objeto executável a partir do código-fonte verificado; e verificar a cobertura e o comportamento do código de objeto executável aplicando-se os casos de teste gerados automaticamente.
2. MÉTODO, de acordo com a reivindicação 1, caracterizado pelo fato de que inclui um caso de teste automatizado e uma unidade de geração de procedimento que autogera os casos de teste a partir do modelo de especificação de software.
3. MÉTODO, de acordo com a reivindicação 1, caracterizado pelo fato de que inclui uma unidade de comprovação de teorema automatizada que implanta técnicas de comprovação de teorema automatizadas para analisar e verificar pelo menos uma dentre uma consistência, uma correção e uma conclusão do modelo de especificação de software.
4. MÉTODO, de acordo com a reivindicação 1, caracterizado pelo fato de que inclui, se um resultado da análise do modelo de especificação de software não for satisfatório, então, ajustar o modelo de especificação de software para corrigir qualquer inconsistência com as exigências de software de linguagem natural.
5. MÉTODO, de acordo com a reivindicação 4, caracterizado pelo fato de que inclui aplicar a análise de exigências ao modelo de especificação de software ajustado.
6. MÉTODO, de acordo com a reivindicação 1, caracterizado pelo fato de que inclui um caso de teste de robustez e com base em exigências automatizado e uma unidade de geração de procedimento que autogera os casos de teste aplicados ao modelo de projeto de software.
7. MÉTODO, de acordo com a reivindicação 1, caracterizado pelo fato de que inclui usar a tecnologia de verificação de modelo para gerar os casos de teste de robustez e com base em exigências aplicados ao modelo de projeto de software.
8. MÉTODO, de acordo com a reivindicação 1, caracterizado pelo fato de que inclui, se um resultado da análise do modelo de projeto de software não for satisfatório, então, ajustar o modelo de projeto de software para corrigir qualquer inconsistência com o modelo de especificação de software.
9. MÉTODO, de acordo com a reivindicação 8, caracterizado pelo fato de que inclui aplicar os casos de teste ao modelo de projeto de software ajustado.
BR102016018127A 2015-08-05 2016-08-04 método para projeto com base em modelo de software de segurança crítica BR102016018127A2 (pt)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US14/819,167 US10346140B2 (en) 2015-08-05 2015-08-05 System and method for model based technology and process for safety-critical software development

Publications (1)

Publication Number Publication Date
BR102016018127A2 true BR102016018127A2 (pt) 2017-06-06

Family

ID=56936596

Family Applications (1)

Application Number Title Priority Date Filing Date
BR102016018127A BR102016018127A2 (pt) 2015-08-05 2016-08-04 método para projeto com base em modelo de software de segurança crítica

Country Status (7)

Country Link
US (1) US10346140B2 (pt)
JP (1) JP6621204B2 (pt)
CN (1) CN106528100B (pt)
BR (1) BR102016018127A2 (pt)
CA (1) CA2937677A1 (pt)
FR (1) FR3039908B1 (pt)
GB (1) GB2542687A (pt)

Families Citing this family (36)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10346140B2 (en) * 2015-08-05 2019-07-09 General Electric Company System and method for model based technology and process for safety-critical software development
US9804954B2 (en) * 2016-01-07 2017-10-31 International Business Machines Corporation Automatic cognitive adaptation of development assets according to requirement changes
US9792204B2 (en) * 2016-02-02 2017-10-17 General Electric Company System and method for coverage-based automated test case augmentation for design models
CA3012848A1 (en) * 2016-02-17 2017-08-24 Silverthread, Inc. Computer-implemented methods and systems for measuring, estimating, and managing economic outcomes and technical debt in software systems and projects
US20180165180A1 (en) * 2016-12-14 2018-06-14 Bank Of America Corporation Batch File Creation Service
EP3545658B1 (en) * 2017-01-23 2021-03-31 Mitsubishi Electric Corporation Evaluation and generation of a whitelist
CN107016085A (zh) * 2017-03-31 2017-08-04 海通安恒科技有限公司 一种计算机化系统验证管理系统
CN107451058B (zh) * 2017-07-31 2023-05-30 北京云测信息技术有限公司 一种软件开发方法和装置
EP3493051A1 (en) * 2017-11-30 2019-06-05 The MathWorks, Inc. System and methods for evaluating compliance of implementation code with a software architecture specification
DE102018003142A1 (de) 2017-12-13 2019-06-13 The Mathworks, Inc. Automatische Einstellung von Multitasking-Konfigurationen für ein Codeprüfsystem
JP6962867B2 (ja) * 2018-06-04 2021-11-05 矢崎総業株式会社 脆弱性評価装置
US10585779B2 (en) 2018-07-30 2020-03-10 General Electric Company Systems and methods of requirements chaining and applications thereof
US10691584B2 (en) * 2018-09-28 2020-06-23 Sap Se Behavior driven development integration with test tool
EP3637249A1 (en) * 2018-10-12 2020-04-15 Tata Consultancy Services Limited Systems and methods for validating domain specific models
CN109542452A (zh) * 2018-11-19 2019-03-29 万惠投资管理有限公司 一种基于ai语义分析的运维管理方法及系统
JP6765554B2 (ja) 2018-12-12 2020-10-07 三菱電機株式会社 ソフトウェア試験装置、ソフトウェア試験方法、および、ソフトウェア試験プログラム
FR3091106B1 (fr) * 2018-12-20 2021-02-12 Commissariat Energie Atomique Système de supervision formelle de communications
CN109933309A (zh) * 2019-03-06 2019-06-25 上海工业控制安全创新科技有限公司 机器学习算法应用于汽车软件开发功能安全的流程方法
CN113519018B (zh) * 2019-03-12 2023-01-03 三菱电机株式会社 移动体控制装置和移动体控制方法
CN110032365A (zh) * 2019-04-19 2019-07-19 广东小天才科技有限公司 一种Sketch图形文件的代码查找方法、装置及终端设备
CN112180890B (zh) * 2019-07-05 2022-01-07 北京新能源汽车股份有限公司 一种测试用例的生成方法、装置及设备
CN110445690A (zh) * 2019-08-16 2019-11-12 北京智芯微电子科技有限公司 电力无线公网通信单元互换性测试软件的设计方法
CN110457031A (zh) * 2019-08-21 2019-11-15 赛尔网络有限公司 一种软件开发方法、装置、设备及介质
CN111274133B (zh) * 2020-01-17 2023-07-25 Oppo广东移动通信有限公司 一种静态扫描方法、装置及计算机可读存储介质
CN111858298B (zh) * 2020-05-29 2022-08-30 卡斯柯信号有限公司 一种基于3v模型的软件测试方法
US11200069B1 (en) 2020-08-21 2021-12-14 Honeywell International Inc. Systems and methods for generating a software application
CN112068805B (zh) * 2020-09-02 2024-05-03 中国航空无线电电子研究所 一种需求开发方法
CN112015658A (zh) * 2020-09-02 2020-12-01 卡斯柯信号(北京)有限公司 一种用于软件集成测试用例的生成方法及装置
BE1028501B1 (nl) * 2020-11-05 2022-02-11 Ivex Een methode en een systeem voor het automatisch genereren van een geïntegreerde broncode voor de elektronische regeleenheid van een AD/ADAS-wegvoertuig
CN112416337B (zh) * 2020-11-11 2023-05-02 北京京航计算通讯研究所 一种面向航天嵌入式系统的软件架构开发系统
EP4016364A1 (en) * 2020-12-16 2022-06-22 The Boeing Company Computing device and method for developing a system model utilizing a simulation assessment module
CN113204330B (zh) * 2021-06-01 2024-03-26 李麟 一种基于人工智能的程序开发设计方法及系统
US11507352B1 (en) 2021-06-15 2022-11-22 International Business Machines Corporation Reducing semantic errors in code generated by machine learning models
CN113791776B (zh) * 2021-08-03 2023-05-26 中国电子科技集团公司第三十研究所 可双向转换的并发性验证方法、系统、设备及存储介质
CN114137873A (zh) * 2021-11-23 2022-03-04 中船动力研究院有限公司 发动机的程序开发方法及装置、发动机的控制系统
US11797317B1 (en) * 2021-12-10 2023-10-24 Amazon Technologies, Inc. Transitioning legacy software to be provably correct

Family Cites Families (41)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6681383B1 (en) 2000-04-04 2004-01-20 Sosy, Inc. Automatic software production system
US7131000B2 (en) * 2001-01-18 2006-10-31 Bradee Robert L Computer security system
GB0113946D0 (en) 2001-06-08 2001-11-14 Secr Defence Automatic Development of Software Codes
US20050020945A1 (en) * 2002-07-02 2005-01-27 Tosaya Carol A. Acoustically-aided cerebrospinal-fluid manipulation for neurodegenerative disease therapy
US7480893B2 (en) 2002-10-04 2009-01-20 Siemens Corporate Research, Inc. Rule-based system and method for checking compliance of architectural analysis and design models
US7228524B2 (en) 2002-12-20 2007-06-05 The Boeing Company Method and system for analysis of software requirements
US20070074180A1 (en) * 2003-12-22 2007-03-29 Nasa Hq's Systems, Methods and Apparatus for Procedure Development and Verification
US7739671B1 (en) * 2003-12-22 2010-06-15 The United States Of America As Represented By The Administrator Of The National Aeronautics And Space Administration Systems, methods and apparatus for implementation of formal specifications derived from informal requirements
US7685576B2 (en) 2004-01-26 2010-03-23 Siemens Corporation System and method for model based system testing of interactive applications
US7392509B2 (en) * 2004-04-13 2008-06-24 University Of Maryland Method for domain specific test design automation
GB0410047D0 (en) 2004-05-05 2004-06-09 Silverdata Ltd An analytical software design system
US7865339B2 (en) 2004-07-12 2011-01-04 Sri International Formal methods for test case generation
EP1622022A1 (de) 2004-07-22 2006-02-01 Siemens Aktiengesellschaft Automatische Erzeugung von Testfällen
JP2007122135A (ja) 2005-10-25 2007-05-17 Hitachi Ltd 開発支援装置、開発支援方法、および、開発支援プログラム
EP1832975A1 (en) 2006-03-09 2007-09-12 Alcatel Lucent Automatic generation of source program
US7523425B2 (en) 2006-04-21 2009-04-21 Alcatel-Lucent Usa Inc. Test case generation algorithm for a model checker
US8176470B2 (en) 2006-10-13 2012-05-08 International Business Machines Corporation Collaborative derivation of an interface and partial implementation of programming code
US20090089618A1 (en) 2007-10-01 2009-04-02 Fujitsu Limited System and Method for Providing Automatic Test Generation for Web Applications
US8307342B2 (en) * 2008-05-14 2012-11-06 Honeywell International Inc. Method, apparatus, and system for automatic test generation from statecharts
JP2009294846A (ja) 2008-06-04 2009-12-17 Denso Corp テストケース生成装置、テストケース生成プログラム、およびテストケース生成方法
US8359576B2 (en) 2008-11-14 2013-01-22 Fujitsu Limited Using symbolic execution to check global temporal requirements in an application
US20110083121A1 (en) * 2009-10-02 2011-04-07 Gm Global Technology Operations, Inc. Method and System for Automatic Test-Case Generation for Distributed Embedded Systems
US20110125302A1 (en) 2009-10-23 2011-05-26 Gm Global Technology Operations, Inc. Method and system for formal safety verification of manufacturing automation systems
EP2369528A1 (en) 2010-03-23 2011-09-28 Siemens Aktiengesellschaft Information processing apparatus, method and protocol for generation of formal requirements specification models
US20120143570A1 (en) 2010-12-03 2012-06-07 University Of Maryland Method and system for ontology-enabled traceability in design and management applications
CN102136047A (zh) * 2011-02-25 2011-07-27 天津大学 一种基于形式化及统一软件模型的软件可信工程方法
US20120246612A1 (en) * 2011-03-23 2012-09-27 Siemens Corporation System and method for verification and validation of redundancy software in plc systems
JP2013058068A (ja) * 2011-09-08 2013-03-28 Panasonic Corp プラットフォームのプログラムおよびそれを搭載した端末装置
KR101408870B1 (ko) 2012-11-06 2014-06-17 대구교육대학교산학협력단 Ｕｍｌ ｓｄ로부터 ｍｃｃｆｇ를 기반으로 하는 다단계 테스트 케이스 생성장치 및 방법
WO2014087427A1 (en) 2012-12-05 2014-06-12 Tata Consultancy Services Limited Method and system for computational design and modeling
WO2014115189A1 (en) 2013-01-28 2014-07-31 Nec Corporation Method and system for transforming specification scripts to program code
JP2015005189A (ja) 2013-06-21 2015-01-08 株式会社オートネットワーク技術研究所 Ｅｃｕ評価装置、コンピュータプログラム及びｅｃｕ評価方法
WO2015040735A1 (ja) 2013-09-20 2015-03-26 株式会社日立製作所 ソフトウェア仕様の形式検証支援装置及びその方法
CN103530228B (zh) * 2013-09-27 2016-09-28 西安电子科技大学 一种基于模型的软件测试方法
CN103678636A (zh) * 2013-12-19 2014-03-26 中山大学深圳研究院 一种构件软件系统可靠性的提高系统及方法
CN103955427B (zh) * 2014-04-29 2016-08-24 探月与航天工程中心 一种安全攸关系统的软件安全性保证的实现方法
CN104182591A (zh) * 2014-09-02 2014-12-03 浪潮(北京)电子信息产业有限公司 一种软件测试需求建模方法
CN104461882B (zh) * 2014-11-29 2017-05-17 中国航空工业集团公司第六三一研究所 一种符合do‑178b/c a级软件的模型验证方法
US10108536B2 (en) * 2014-12-10 2018-10-23 General Electric Company Integrated automated test case generation for safety-critical software
US9747079B2 (en) * 2014-12-15 2017-08-29 General Electric Company Method and system of software specification modeling
US10346140B2 (en) * 2015-08-05 2019-07-09 General Electric Company System and method for model based technology and process for safety-critical software development

Also Published As

Publication number Publication date
JP6621204B2 (ja) 2019-12-18
US20170039039A1 (en) 2017-02-09
CN106528100A (zh) 2017-03-22
GB201613356D0 (en) 2016-09-14
CN106528100B (zh) 2020-06-09
JP2017033562A (ja) 2017-02-09
FR3039908A1 (fr) 2017-02-10
FR3039908B1 (fr) 2022-12-23
CA2937677A1 (en) 2017-02-05
GB2542687A (en) 2017-03-29
US10346140B2 (en) 2019-07-09

Similar Documents

Publication Publication Date Title
BR102016018127A2 (pt) método para projeto com base em modelo de software de segurança crítica
JP6607565B2 (ja) セーフティクリティカルソフトウェアのための統合された自動テストケース生成
Chauhan et al. Latest research and development on software testing techniques and tools
WO2006038394A1 (ja) ソースコード検査器、方法、プログラム及び記憶媒体
Chong et al. Code-level model checking in the software development workflow
US10049031B2 (en) Correlation of violating change sets in regression testing of computer software
US8719771B2 (en) Method and system for test reduction and analysis
US8868976B2 (en) System-level testcase generation
JP2009087354A (ja) ウェブアプリケーションの自動テスト生成システム及び方法
US10592623B2 (en) Assertion statement check and debug
JP2009211503A (ja) ソースコード検証装置、及びソースコード検証方法
Bandara et al. Identifying software architecture erosion through code comments
US10169217B2 (en) System and method for test generation from software specification models that contain nonlinear arithmetic constraints over real number ranges
Hovsepyan et al. Model-driven software development of safety-critical avionics systems: an experience report
Matragkas et al. A Traceability-Driven Approach to Model Transformation Testing.
Burnard et al. Verifying and validating automatically generated code
Abraham Verification and validation spanning models to code
Langari et al. Quality, cleanroom and formal methods
KR101601741B1 (ko) 서로 다른 언어로 작성된 프로그램들의 동일성을 검증하는 검증장치
Honda et al. Range analyzer: An automatic tool for arithmetic overflow detection in model-based development
Lin et al. Quality assurance through rigorous software specification and testing: a case study
Alves et al. A practical formal approach for requirements validation and verification of dependable systems
JP5736588B2 (ja) ソースコード変換方法及びソースコード変換プログラム
Johnsen Quality Assurance for Dependable Embedded Systems
Talekar et al. CI-CD Workflow For Embedded System Design

Legal Events

Date Code Title Description
B03A Publication of a patent application or of a certificate of addition of invention [chapter 3.1 patent gazette]
B15K Others concerning applications: alteration of classification

Ipc: G06F 8/35 (2018.01), G06F 8/20 (2018.01), G06F 11/

B06U Preliminary requirement: requests with searches performed by other patent offices: procedure suspended [chapter 6.21 patent gazette]
B11B Dismissal acc. art. 36, par 1 of ipl - no reply within 90 days to fullfil the necessary requirements