Embed Size (px)
Citation preview
Síntese de Algumas Iniciativas para Definiçãode um Processo de Desenvolvimento de
Software para Sistemas Embarcados Críticos,no âmbito do INCT-SEC
Erik Aceiro Antonio11, Guilherme Freire21, JuciaraNepomuceno31, Bárbara Castanheira41, Leonardo M. Pedro52,Glauco A. P. Caurin62, Rafael Messias Martins 73, José CarlosMaldonado83, Fabiano Cutigi Ferrari91 e Sandra Fabbri101
1Departamento de Computação – Universidade Federal de SãoCarlos (DC–UFSCar) São Carlos – SP – Brasil
2Escola de Engenharia de São Carlos (EESC–USP) São Carlos –SP – Brasil
3Instituto de Ciências Matemáticas e de Computação(ICMC–USP) São Carlos – SP – Brasil
Agosto, 2011
[email protected][email protected][email protected][email protected]@[email protected]@[email protected]
2
Sumário
1 Introdução 1
2 Metodologia 3
3 Estudo de Caso: Mão Robótica 6
4 Representação em Alto Nível de Sistemas Embarcados Crí-ticos Utilizando a Técnica UML Statechart 8
5 Especificação de Requisitos no Contexto do Processo 115.1 Atividades de V&V em Modelos . . . . . . . . . . . . . . . . . 12
6 Atividades de V&V em Código 13
7 Conclusão 15
1
Abstract
Context: Usually, developers of critical embedded systems create a newsystem starting with low level abstractions like Simulink-based models. Thishardens the system?s comprehension and does not provide adequate docu-mentation. Goal: This paper presents a series of pieces of research whosemain, common goal is the definition of a process for the development of cri-tical embedded systems. The pro cess shall address activities related to re-quirement engineering, modeling and V&V. Method: To define the process,we started with the Simulink model and we are cur rently defining artifactsbased on reverse and forward software engineering. Results and conclu-sion: The current status gives evidence of the aimed contribution based onsome techniques to compose the process. Examples are UML Statechartsand SysML. Besides that, metrics have been applied to assess the quality ofthe produced artifacts.
Resumo
Contexto: Em geral, os desenvolvedores de Sistemas Embarcados Críticosiniciam o desenvolvimento a partir de modelos de baixo nível, como modelosSimulink. Isso dificulta o entendimento da aplicação e não provê uma docu-menta ção apropriada. Objetivo: O objetivo deste artigo é apresentar ostrabalhos que estão sendo conduzidos com o intuito de definir um processopara desenvolvimento de sistemas embarcados críticos, contemple atividadesde engenharia de requisitos, de modelagem, e de V&V. Método: Para de-finir o processo tem-se partido do modelo Simulink e definido os artefatoscom base em atividades de engenharia reversa e reengenharia. Resultadose conclusões: No estado atual dos trabalhos, os resultados obtidos dão in-dícios da contribuição de algumas técnicas para compor o processo, como porexemplo, UML Statecharts, SysML. Além disso, métricas tem sido aplicadaspara avaliar a qualidade dos modelos e do código.
Capítulo 2
Introdução
Sistemas embarcados tem modificado rapidamente a forma como a sociedadevem lidando com os diferentes tipos de tecnologias. Nos últimos anos tem-se observado a aplicação de sistemas embarcados em diferentes domínios,tais como telecomunicações, robótica, indústria automotiva, indústria área,em sensores de usinas nucleares, residências e entretenimento (Simon 1999).O impacto da variabilidade de funcionalidades de tais sistemas tem levado auma crescente produção de sistemas embarcados com demandas extras funci-onais – levantamento de requisitos, documentação, segurança, confiabilidadee curtos prazos de entregas (Liggesmeyer and Trapp 2009).
A complexidade inerente dos diferentes domínios de aplicações de siste-mas embarcados, aliada com a necessidade por se detectar defeitos o maisrapidamente possível, tem sido um dos fatores chave no desenvolvimento desistemas. Esse fator tem levado pesquisadores a buscarem cada vez maiscritérios, ferramentas, métodos e processos que promovam a qualidade dosoftware embarcado. No desenvolvimento de sistemas embarcados críticos,outra preocupação e alvo de pesquisas tem sido os riscos ligados com a produ-ção de software em diferentes áreas. Em 2004, por exemplo, (Leveson 2004)discutiu diferentes tipos de falhas com veículos aéreos, todas causadas porsoftware. No trabalho de (Cu et al. 2011) pode-se observar uma iniciativa deuso de técnicas de Verificação e Validação (V&V), ressaltando a importânciaem usá-las para assegurar a confiabilidade de Sistemas Embarcados Críticos(SEC) em áreas como a medicina, em equipamentos que bombeiam o san-gue para o coração, bem como na indústria automobilística e em sistemas decontrole aéreo.
Tradicionalmente, a Engenharia de Software procura propor e definir umconjunto de técnicas e artefatos que promovam a qualidade do software fi-nal produzido. Dessa forma, tem-se verificado, iniciativas de associação daEngenharia de Software no contexto de Sistemas Embarcados, tanto na li-
1
teratura como na prática. Mesmo as iniciativas existentes, verifica-se aindaa necessidade por processos de desenvolvimento de software que promovama qualidade do software embarcado. Aliado a isso, ressalta-se que uma dasimportantes atividades da Engenharia de Software é a definição e elaboraçãode modelos de processos de desenvolvimento.
Com base nesse contexto, o objetivo deste artigo é retratar o projeto quevem sendo desenvolvido pelo grupo de pesquisa representado pelos autores.Esse projeto envolve trabalhos de mestrado e de doutorado e tem por objetivodefinir um processo de desenvolvimento de software embarcado que contribuapara melhorar a qualidade do desenvolvimento e sistematizar as atividadesenvolvidas e que, ao mesmo tempo seja um processo ”leve”, que incentive osdesenvolvedores de SE a usá-lo.
Este artigo está organizado da seguinte forma: A Seção 2 descreve ametodologia seguida para atingir o objetivo principal deste trabalho, que é adefinição do processo de desenvolvimento. A Seção 3 introduz uma aplicaçãode SEC que é utilizada como estudo de caso pelos autores deste trabalho.As Seções 4, 5, 6 e 7 descrevem, respectivamente, as etapas de engenhariareversa e avante de modelos para SECs, a especificação dos requisitos e aavaliação dos artefatos gerados durante o processo. Por fim, na Seção 8 édescrito o estado atual do trabalho e são sumarizadas as próximas etapas aserem realizadas.
2
Capítulo 3
Metodologia
A metodologia que vem sendo adotada para definir esse processo de desenvol-vimento de SEs é a seguinte: em primeiro lugar, identificou-se, no contextode SEs, que os desenvolvedores desse tipo de aplicação, iniciam o desen-volvimento a partir de uma etapa bem próxima da implementação, usandotécnicas de modelagem próprias para esse domínio, como Simulink, Lab-VIEW, e outras. Assim, tanto com base na literatura, como na prática quese observou em alguns grupos participantes do INCT-SEC, não existe umprocesso de desenvolvimento de SEs, baseado nos conceitos da engenharia desoftware. Além disso, identificou-se, no contexto do INCT-SEC, que muitosgrupos utilizam Simulink para desenvolver SEs e então, decidiu-se desenvol-ver o processo, tendo como base essa técnica; futuramente, após o processoestar definido, será feita uma avaliação em relação às outras técnicas exis-tentes.
Assim, considerando que o objetivo final é definir um processo de enge-nharia avante que auxilie em todas as etapas iniciais do desenvolvimento desoftware, até o momento em que se deva elaborar um modelo mais direcio-nado para esse domínio, como um modelo Simkulink, a estratégia que temsido adotada é a seguinte: partindo-se do modelo Simulink, identifica-se ummodelo que possa representar o Simulink em um nível de abstração diferente,ou seja, aplica-se a engenharia reversa do Simulink; em seguida, para avaliarse a representação escolhida é apropriada ou não, aplica-se a reengenharia,partindo da abstração realizada, até chegar ao Simulink novamente. Essaestratégia está sendo aplicada sucessivamente, até que consigamos delinearum processo, desde a elicitação de requisitos até o modelo Simulink, que con-tribua para sistematizar o desenvolvimento, e melhorar a qualidade ao longode todo o processo.
A definição desse processo de desenvolvimento de SEs envolve trabalhosde mestrado e de doutorado. Temas que estão sendo considerados no projeto
3
são: (i) representação do modelo Simulink em um nível mais alto de abs-tração, com o uso de UML Statecharts (mestrado de Guilherme Freire); (ii)representação dos requisitos dos SEs, tanto no que se refere à fase de elicita-ção, quanto à completitude do modelo de alto, e sua capacidade de armazenardetalhes que permitam chegar ao modelo Simulink pela engenharia avante(mestrado de Juciara Nepomuceno); (iii) definição de tarefas de qualidadeao longo do processo, relacionadas com padrões de certificação (mestrado deBárbara Castanheira); (iv) junção das partes exploradas em i, ii e iii, paracomposição do processo almejado, o qual será todo baseado em atividades deV&V, com foco em atividades de inspeção e técnicas de leitura (doutoradode Erik Aceiro). Além disso, também faz parte do objetivo geral do grupo depesquisa o tema (v), que corresponde ao impacto desse processo na qualidadedo código gerado (mestrado de Rafael Messias).
Para a elaboração desse processo, está sendo feita uma caracterizaçãodesses temas por meio de mapeamentos sistemáticos Kitchenham (2004),que estão sendo conduzidos no âmbito do trabalho de doutorado sobre: (a)processos de dsenvolvimento de sistemas embarcados; (b) modelos de arqui-tetura de referência para sistemas embarcados; (c) processos que envolvamatividades de V&V; (d) técnicas utilizadas para elaboração de modelos demais alto nível; (e) identificação de relatos sobre dificuldade de compreensãodos modelos no contexto de sistemas embarcados; e (f) métricas utilizadasno contexto de sistemas embarcados.
Em relação aos temas (a),(b) e (c) podemos citar as propostas SARAH(Software Architecture Reliability Analysis Approach) (Tekinerdogan et al.2008) e FMEA (Failure Modes and Effects Analysis) (Haapanen and Helmi-nen 2002) que procuram identificar falhas nos estágios iniciais do processode desenvolvimento e também da definição da arquitetura de sistemas em-barcados. Arcuri et al. (2010) apresentam a aplicação de uma abordagemcaixa-preta para a atividade de teste. Os autores modelam o RTES (Real-Time Embedded Systems) com UML e o perfil MARTE para a produção decasos de testes que são gerados a partir de modelos.
Os temas (d) e (e), tratam da complexidade de sistemas embarcados quesão modelados com Model-Based Design (MBD) e Actor-Oriented Design(AOD) (Lee 2004). Identificou-se que em abordagens (AOD/MBD) um fa-tor de impacto que caracteriza um modelo são os diferentes tipos de estilosde projeto que um projetista de sistema embarcado pode usar. Por exem-plo, Kehtarnavaz (2006) & Ebert and Jones (2009) apresentaram modelos nocontexto de sistemas embarcados com mais alto nível de abstração. Nos tra-balhos de Polzer et al. (2010) é possível evidenciar a carência de elementos deabstração em modelos Simulink, que é uma das mais bem aceitas linguagensde modelagem (MBD). O mesmo autor ainda relata a dificuldade de com-
4
preensão de modelos Simulink. Para reduzir essa dificuldade inerente dosmodelos em Simulink, Polzer et al. (2010) propõem o uso de um conjunto devisualizações paralelas ao modelo Simulink, em EMF (Eclipse Modeling Fra-mework). Finalmente, o tema (f) associa o uso de métricas com modelos, asmétricas são ferramentas de engenharia de software que podem ser aplicadasa código e/ou modelos e permitem a identificação de parâmetros que podemguiar o desenvolvimento de um sistema embarcado.
Em suma, o trabalho de doutorado vai agregar os temas que estão sendotratados nos trabalhos de mestrado, no que se refere ao processo de desenvol-vimento, desde a elicitaçãode requisitos até a construção do modelo Simulink,conforme comentado nesta seção. Além disso, será avaliado o impacto desseprocesso no código gerado quando decorrente de sua aplicação. Os trabalhosque estão mais adiantados são comentados nas seções seguintes, com base emuma aplicação relativa a uma mão mecânica, a qual é explicada na próximaseção.
5
Capítulo 4
Estudo de Caso: Mão Robótica
A realização de tarefas de manipulação de objetos utilizando mos robóticas,um dos maiores desafios da robótica (Bicchi and Kumar 2001). O desen-volvimento de sistemas embarcados para a manipulação de objetos envolvevários campos da ciência, que devem ser considerados e trabalhados em con-junto: computação, eletrônica e mecânica. Neste trabalho, utiliza-se comoestudo de caso um sistema embarcado que controla a Kanguera Hand (Kan-guera Project 2010), uma mão robótica antropomórfica composta por cincodedos híbridos independentes. Cada um dos dedos constituiu por quatroarticulares, que são controladas por três motores virtuais e um motor real.A Kanguera Hand permite realizar manipulações complexas devido ao altograu de liberdade de cada dedo (degrees of freedom - DOF ).
Para executar uma tarefa de manipulação de um lápis, foi desenvolvidoum modelo Simulink (MathWorks 2011), descrito na Seção 4 deste artigo.A manipulação do lápis exige o movimento independente de três dedos. AFigura 1 ilustra a posição inicial e final da tarefa. A trajetória do motor éinformada previamente por meio do controlador como referência. Para gerarmovimentos apropriados, essa tarefa de manipulação requer que o movimentode cada articulação seja combinado com a fora e torque apropriado. Dessaforma, durante uma tarefa de manipulação, velocidade e torque devem sercontrolados de forma síncrona.
6
Figura 4.1: Exemplo de manipulao de objetos com a Kanguera Hand.
7
Capítulo 5
Representação em Alto Nível deSistemas Embarcados CríticosUtilizando a Técnica UMLStatechart
A técnica Statechart foi apresentada por Harel (1987) com intuito de estendero conceito de máquinas de estados adicionando hierarquia, concorrência ecomunicação em broadcast. A partir desses conceitos introduzidos por Harel,sistemas embarcados podem ser modelados para expressar esses conceitos.
Neste trabalho, procurou-se utilizar a técnica UML Statechart – desteponto em diante referenciada como Statechart – para explorar a representa-ção de um modelo Simulink em um nível mais alto de abstração. A técnicafoi selecionada depois de uma seção de brainstorming com especialistas daárea de Engenharia de Software. O Statecharts foi selecionado pois fornece osrecursos necessários para modelar as características e representar o sistemaindependentemente da plataforma de desenvolvimento. O objetivo é apoiara definição de um processo de engenharia avante para o desenvolvimento deSECs. O estudo inicia a partir de um modelo Simulink já elaborado, o qual ésubmetido a um processo de reengenharia, conforme ilustrado na Figura 4.1(mais detalhes são apresentado a seguir, nesta seção). O estudo de caso emquestão está associado ao sistema da mão robótica Kanguera Hand, descritona Seção 3.
O modelo Simulink – Figura 4.2(a) – é parte de uma tarefa de manipula-ção de objetos executada pela mão robótica. No modelo estão implementadasas funcionalidades para a execução do movimento de fechar um dedo da mão.Ressalta-se que durante a fase de desenvolvimento não foram elaborados mo-delos de mais alto nível ou documento para especificação do sistema que
8
Extração de Informação
Reconstruçãodo Modelo
Modelo SimulinkOriginal
Modelo Statechart
Modelo Simulink
Reconstruído
ParalelismoParalelismoRequisitosFuncionaisRequisitosFuncionais
RequisitosNão Funcionais
RequisitosNão Funcionais
Figura 5.1: Processo de Reengenharia (adaptado de Pressman (2005)).
pudesse auxiliar a fase de implementação. O modelo Simulink original foielaborado iterativamente à medida que o desenvolvedor simulava e testava osistema. Assim, o modelo foi evoluindo ao passo que novos requisitos foramsurgindo e defeitos eram corrigidos.
(a) modelo Simulink original
(b) diagrama Statechart
(c) modelo Simulink reconstruído
Figura 5.2: Transformação de modelos Simulink → Statechart → Simulink.
Para realizar a reengenharia do modelo Simulink, ilustrada na Figura 4.2,inicialmente tentou-se organizar o modelo de forma a representá-lo em umnível mais alto de abstração; entretanto, essa primeira tentativa não apre-sentou resultados satisfatórios. Foi então solicitada a presença do engenheirodesenvolvedor para auxiliar na extração dos requisitos a partir do modeloSimulink.
No processo de engenharia reversa, representado na Figura 4.1, a etapaExtração de Informação foi realizada com o objetivo de identificar atividadesconcorrentes e o conjunto de requisitos funcionais e não funcionais do sistemada Kanguera Hand. Durante essa etapa, o desenvolvedor do modelo Simulinkoriginal identificou um conjunto semelhante de subsistemas. Um exemploé mostrado na Figura 4.3, a qual destaca o mapeamento de elementos domodelo Simulink para elementos do diagrama Statechart.
Após o sistema ter sido abstraído para o modelo Statechart – Fi-
9
Figura 5.3: Estados Correspondentes a Conjunto de Blocos.
gura 4.2(b) –, o engenheiro desenvolvedor foi capaz de reelaborar o modeloSimulink, criando o novo modelo ilustrado na Figura 4.2(c). A melhora domodelo é notória, permitindo melhor entendimento, clareza e facilidade demanutenção.
É importante salientar que, no contexto deste trabalho, o modelo Simu-link e o diagrama Statechart foram considerados complementares, podendoser utilizados em conjunto com o objetivo de melhorar a compreensão do SECe diminuir a sua complexidade. Entretanto, perdem-se informações ao repre-sentar um modelo de mais baixo nível em um nível mais alto de abstração.Para capturar essas informações, investigou-se a especificação de requisitosno contexto de SECs. Os resultados são descritos na próxima seção.
10
Capítulo 6
Especificação de Requisitos noContexto do Processo
Neste trabalho, duas técnicas de modelagem para elicitação de requisitosestão sendo investigadas para SECs. A primeira consiste no uso de Diagramade Requisitos da SysML (System Modeling Language)(Object ManagementGroup 2010) e a segunda em Diagramas Activity-chart de Harel (1987). Essasduas técnicas estão sendo comparadas a fim de se identificar as respectivasdiferenças entre cada uma delas.
A linguagem de modelagem SysML é um subset da UML 2.0, em quequatro dos seus diagramas foram mantidos (Máquinas de Estado, Sequên-cia, Casos de Uso e Pacotes), três foram adaptados (Atividades, Definiçãode Blocos e de Blocos Internos) e dois foram acrescentados (Requisitos e oParamétrico). Uma das características marcantes da SysML é a capacidadede reuso, composição e a rastreabilidade dos requisitos em diferentes tiposde artefatos.
Diagramas Activity-chart procuram explorar decomposição funcional dasatividades. As atividades são então descritas com maior detalhe com auxi-lio de itens de dados e sinais de controle, compondo um fluxo de informa-ção. A Figura 5.1 mostra as duas abordagens aplicadas para o contexto damão robótica. Como principal vantagem da linguagem UML/SysML sobre oActivity-chart, vale destacar por exemplo, o uso de estereótipos para a rastre-abilidade dos requisitos ao longo dos artefatos gerados por um processo. Essefato é importante, visto que os SECs utilizam-se de proprieades e restriçõesimportantes na fase de especificação que podem ser propagadas para outrasfases tardias de um processo.
11
Figura 6.1: (a) Diagrama de Requisitos da SysML. (b) Diagrama Activity-Chart.
6.1 Atividades de V&V em ModelosNo contexto do processo de desenvolvimento a ser proposto, um conjunto demétricas para modelos estão sendo investigadas. Tais métricas visam avaliarmodelos Simulink em termos de proprieades internas, como por exemplo,MC/DC (Modified Condition/Decision Coverage).
Além do uso de métricas, atividades de testes funcionais em modelosforam realizadas a partir do framework mlUnit1. Esse framework permitedefinir um conjunto de casos de testes funcionais para um modelo Simulink.Esse conjunto de casos de teste foi aplicado no modelo antes e depois pro-cesso de re-engenharia. Assim, para o conjunto de casos de teste elaborados,foi possível avaliar que ambos os modelos (original e reconstruído) estavamapresentando a mesma resposta em termos do comportamento funcional dosmodelos.
1Disponível em http://sourceforge.net/projects/mlunit/
12
Capítulo 7
Atividades de V&V em Código
Métricas de código fonte, oferecem a oportunidade de analisar a flexibilidade,complexidade e manutenibilidade do código (Sato et al. 2007). Por outrolado, medidas de teste estrutural, obtidas a partir da execução monitorada dosoftware com um conjunto específico de entradas, refletem tanto a qualidadedos testes quanto a confiabilidade do software (Lanza and Ducasse. 2002).
A plataforma Qualipso oferece uma possibilidade para o preenchimentodessa lacuna e, portanto, a avaliação de qualidade de SECs tendo em vistatanto o código quanto os testes. Nessa plataforma são integradas diversasferramentas de avaliação de qualidade de software e testes; exemplos são aJaBUTi Service (Eler et al. 2009) e a Kalibro (Meirelles et al. 2010). Todosos dados gerados por essas ferramentas – periodicamente para cada projetode software – são armazenados em uma base central, de onde podem seranalisados individualmente ou com o uso de modelos pré-definidos. Cadaferramenta é integrada à plataforma a partir de um extrator que as executae obtém as análises dos projetos de software selecionados. Um exemplo derelatório gerado pela plataforma de qualidade Qualipso pode ser visto naFigura 6.1.
13
Figura 7.1: Exemplo de relatrio gerado na plataforma Qualipso
14
Capítulo 8
Conclusão
Este artigo apresentou o projeto que vem sendo desenvolvido pelos autores,no contexto do INCT-SEC. O objetivo desse projeto é definir um processoque contemple atividades iniciais do ciclo de desenvolvimento de software, en-volvendo o tratamento dos requisitos, e a elaboração de modelos, no que dizrespeito a modelos de mais alto nível, que possam contribuir com a elabora-ção de modelos de baixo nível, como modelos Simulink. Além disso, deseja-seavaliar também o impacto da adoção de um processo no código gerado, umavez que ele deve contemplar atividades de V&V, com o intuito de melhorara qualidade do sistema gerado. A definição desse processo vem sendo rea-lizada com base em aplicações já existentes, o que tem contribuído muitocom a estratégia que foi definida para condução dos trabalhos. As propostaspodem ser exploradas e comparadas com a solução existente, o que permiteavaliar se as escolhas ao longo dos trabalhos trazem contribuição e melhoriasà aplicação. Uma preocupação é que o processo seja capaz de sistematizaro desenvolvimento de SEs, mas que não seja um processo sobrecarregado deartefatos, ao ponto de inviabilizar o seu uso. Para contemplar essa caracte-rística, estudos experimentais têm sido planejados para avaliar as etapas queestão sendo conduzidas. Os principais avanços conseguidos até o momentoestão relacionados a três pontos: à modelagem de mais alto nível do modeloSimulink; às representações dos requisitos, tanto no que se referem à fase deelicitação como à passagem do modelo alto nível para o modelo Simulink; eàs atividades de V&V que vêm sendo exploradas tanto no código como nomodelo. Os trabalhos futuros correspondem à continuidade dos trabalhosenvolvidos, para que se chegue à definição do processo desejado.
15
Referências Bibliográficas
Arcuri, A., Iqbal, M. B., and Briand, L. (2010). Black-box system testingof real-time embedded systems using random and search-based testing. InLecture Notes in Computer Science (including subseries Lecture Notes inArtificial Intelligence and Lecture Notes in Bioinformatics.
Bicchi, A. and Kumar, V. (2001). Robotic grasping and manipulation. In Ni-cosia, S., Siciliano, B., Bicchi, A., and Valigi, P., editors, Ramsete, volume270 of Lecture Notes in Control and Information Sciences, pages 55–74.Springer Berlin / Heidelberg.
Cu, C., Jeppu, Y., Hariram, S., Murthy, N., and Apte, P. (2011). A newinput-output based model coverage paradigm for control blocks. In Aeros-pace Conference, 2011 IEEE, pages 1 –12.
Ebert, C. and Jones, C. (2009). Embedded software: Facts, figures, andfuture. Computer, 42:42–52.
Eler, M. M., Endo, A. T., Masiero, P. C., Delamaro, M. E., Maldonado, J. C.,Vincenzi, A. M. R., Chaim, M. L., and Beder, D. M. (2009). JaBUTiSer-vice: A web service for structural testing of java programs. In 33rd AnnualIEEE Software Engineering Workshop (SEW-33), Skövde, Sweden.
Haapanen, P. T. I. and Helminen, A. T. (2002). Failure mode and effectsanalysis of software-based automation systems. VTT Industrial Systems.
Harel, D. (1987). Statecharts: A visual formalism for complex systems.Science of Computer Programming, 8:231–274.
Kanguera Project (2010). Project website. Online. http://www.mecatronica.eesc.usp.br/wiki/index.php/Kanguera_Project - aces-sado em 26/10/2011.
Kehtarnavaz, N.; Gope, C. (2006). Dsp system design using labview andsimulink: A comparative evaluation. In IEEE International Conferenceon, Acoustics (ICASSP), Speech and Signal Processing.
16
Kitchenham, B. (2004). Procedures for performing systematic reviews. JointTechnical Report TR/SE-0401 (Keele) - 0400011T.1 (NICTA), SoftwareEngineering Group - Department of Computer Science - Keele Univer-sity and Empirical Software Engineering - National ICT Australia Ltd,Keele/Staffs-UK and Eversleigh-Australia.
Lanza, M. and Ducasse., S. (2002). Understanding software evolution using acombination of software visualization and software metrics. In Proceedingsof LMO 2002 (Languages et Modeles a Objets), pages 135–149. HermesPublications.
Lee, A. E. (2004). Actor-oriented design: A focus on domain-specific langua-ges for embedded systems.
Leveson, N. G. (2004). The role of software in spacecraft accidents. AIAAJournal of Spacecrafts and Rockets, 41:564–575.
Liggesmeyer, P. and Trapp, M. (2009). Trends in embedded software engi-neering. IEEE Software, 26:19–25.
MathWorks (2011). Simulink - simulation and model-based design. On-line. http://www.mathworks.com/products/simulink/index.html -acessado em 26/10/2011.
Meirelles, P. R. M., Santos Jr., C. D., Terceiro, A., Miranda, J., Chavez, C.,and Kon, F. (2010). A study of the relationships between source code me-trics and attractiveness in free software projects. In SBES’2010 – SimpósioBrasileiro de Engenharia de Software, Salvador–BA.
Object Management Group (2010). Systems modeling language - documentformal/2010-06-01. Online. http://www.omg.org/spec/SysML/1.2/PDF -acessado em 26/10/2011.
Polzer, A., Hedenetz, B., Merschen, D., Botterweck, G., Thomas, J., andKowalewski, S. (2010). View-supported rollout and evolution of model-based ecu applications. In Proceedings of the 7th International Workshopon Model-Based Methodologies for Pervasive and Embedded Software,MOMPES ’10, pages 37–44, New York, NY, USA. ACM.
Pressman, R. S. (2005). Software engineering - A Practitioner’s Approach.McGraw-Hill, New York/NY - USA, 6th. edition.
Sato, D., Goldman, A., and Kon, F. (2007). Tracking the evolution of objectoriented quality metrics. In Proceedings of the 8th International Conference
17
on Extreme Programming and Agile Processes in Software Engineering (XP2007), pages 84–92.
Simon, D. E. (1999). An Embedded Software Primer. Addison-Wesley Pro-fessional.
Tekinerdogan, B., Sozer, H., and Aksit, M. (2008). Software architecturereliability analysis using failure scenarios. J. Syst. Softw., 81:558–575.
18
