PM-MDA: um método para o desenvolvimento de modelos de plataforma no contexto da MDA

Texto

(1)UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA ELÉTRICA E INFORMÁTICA INDUSTRIAL. INALI WISNIEWSKI SOARES. PM-MDA: UM MÉTODO PARA O DESENVOLVIMENTO DE MODELOS DE PLATAFORMA NO CONTEXTO DA MDA. TESE. CURITIBA 2012.

(2) INALI WISNIEWSKI SOARES. PM-MDA: UM MÉTODO PARA O DESENVOLVIMENTO DE MODELOS DE PLATAFORMA NO CONTEXTO DA MDA. Tese apresentada ao Programa de Pós-Graduação em Engenharia Elétrica e Informática Industrial, da Universidade Tecnológica Federal do Paraná, como requisito parcial para obtenção do título de “Doutor em Ciências” - Área de Concentração: Engenharia de Computação. Orientador: Prof. Dr. Paulo Cézar Stadzisz Co-orientador: Prof. Dr. Jean Marcelo Simão. CURITIBA 2012.

(3) Dados Internacionais de Catalogação na Publicação S676. Soares, Inali Wisniewski PM-MDA : um método para o desenvolvimento de modelos de plataforma no contexto da MDA / Inali Wisniewski Soares. — 2012. 241 f. : il. ; 30 cm Orientador: Paulo Cezar Stadzisz. Co-orientador: Jean Marcelo Simão. Tese (Doutorado) – Universidade Tecnológica Federal do Paraná. Programa de Pósgraduação em Engenharia Elétrica e Informática Industrial. Área de concentração: Engenharia da Computação, Curitiba, 2012. Bibliografia: p. 177-188. 1. Arquitetura de software orientada a modelos. 2. Sistemas embarcados (Computadores). 3. Sistemas embutidos de computador. 4. UML (Linguagem de modelagem padrão). 5. Engenharia elétrica – Teses. I. Stadzisz, Paulo Cezar, orient. II. Simão, Jean Marcelo. III. Universidade Tecnológica Federal do Paraná. Programa de Pós-graduação em Engenharia Elétrica e Informática Industrial. IV. Título. CDD (22. ed.) 621.3. Biblioteca Central da UTFPR, Campus Curitiba.

(4)

(5) Ao Marlon, ao André, a Maria Iraci e ao Vitoldo..

(6) AGRADECIMENTOS. Ao professor Paulo Cézar Stadzisz que com dedicação, conhecimento e experiência orientou este trabalho. Ao professor Jean Marcelo Simão (co-orientador), pelas importantes contribuições para a melhoria deste trabalho. Aos professores Alessandro Fabrício Garcia, Maria Salete Marcon Gomes Vaz, Marcos Antônio Quináia e Cesar Augusto Tacla, membros da banca examinadora, pelas valiosas observações e sugestões apresentadas. Ao Marlon, amor da minha vida, por seu apoio dedicado durante a realização deste trabalho. Ao André, meu filho, por trazer tanta alegria à minha vida e me fazer muito feliz durante a realização deste trabalho. Aos meus pais Vitoldo e Maria Iraci, pelo amor, apoio, dedicação e pelas oportunidades propiciadas. Aos meus queridos irmãos Loian, Valéria, Marcia e Vitor e todas as pessoas da minha família por todo amor e apoio dedicados. Às minhas queridas amigas Luciane e Josiane com as quais foi possível compartilhar todos esses anos de estudos, desafios e vitórias. Aos demais amigos, professores e funcionários (em especial à secretária do CPGEI Terezinha Strapasson, pela eficiência e dedicação) da UTFPR, pelo apoio, amizade e incentivo. Aos amigos do DECOMP-UNICENTRO pelo apoio, amizade e incentivo. A todas às pessoas, que embora não tenham sido citadas aqui, contribuíram de diversas maneiras para a realização deste trabalho..

(7) RESUMO. SOARES, Inali Wisniewski. PM-MDA: Um Método para o Desenvolvimento de Modelos de Plataforma no contexto da MDA. 2012. 241 f. Tese de Doutorado – Programa de PósGraduação em Engenharia Elétrica e Informática Industrial (CPGEI), Universidade Tecnológica Federal do Paraná (UTFPR). Curitiba, 2012.. Esta tese propõe um método denominado PM-MDA para o desenvolvimento de Modelos de Plataforma (Platform Model - PM) no contexto da abordagem Model Driven Architecture (MDA). O método PM-MDA tem como foco o desenvolvimento de projetos de Software embarcado baseados em Sistemas Operacionais em Tempo Real (Real-Time Operating System - RTOS). Adicionalmente, este estudo define um perfil UML 2.0 para modelagem da aplicação e plataforma de software embarcado denominado Profile for modeling Application and Platform of Embedded Software (PROAPES) que é usado no método PM-MDA. Tal perfil define um conjunto de estereótipos para descrever genericamente Modelos de Plataforma e Modelos Independentes de Plataforma (Platform Independent Model - PIM). Além disso, são definidas extensões desse perfil, tal como o perfil PROAPESX que permite a modelagem de PMs para versões do RTOS X Real-Time Kernel e hardware associados. Além disso, o perfil PROAPES possibilita vincular um PIM a um PM, permitindo que esses modelos sejam inseridos como atributos de entrada em uma Transformação de Modelos. No contexto da MDA, esse perfil constitui-se em um metamodelo de plataforma (um metamodelo de uma família de plataformas similares) para a construção de modelos de plataforma. Desse modo, um PM é usado como parte fundamental para o desenvolvimento de software embarcado na abordagem MDA, fornecendo meios de obter independência de plataforma. Em abordagens atuais de MDA, as transformações de modelos empregam implicitamente os modelos de plataforma. Como os interesses referentes à plataforma não são separados dos interesses referentes às transformações de modelos, para cada plataforma requerida deve existir uma ou mais transformações de modelos correspondentes que são configuradas especificamente para aquela plataforma. O resultado são processos de transformações de modelos difíceis de serem automatizados. No domínio de sistemas embarcados, o uso de MDA é ainda mais importante devido à heterogeneidade de plataformas e à complexidade destes sistemas. O método PMMDA, que faz uso do perfil PROAPES, visa sistematizar o processo de criação e disponibilização de modelos de plataforma separados do processo de transformação de modelos, possibilitando a geração de processos de transformações de modelos eficientes e adaptáveis. Palavras-chave: Model Driven Architecture (MDA). Modelo de Plataforma. Perfil UML. Software Embarcado..

(8) ABSTRACT. SOARES, Inali Wisniewski. PM-MDA: A Method for the Development of Platform Models in the context of MDA. 2012. 241 f. Thesis – Graduate Program in Electric Engineering and Industrial Informatics (CPGEI), Paraná Federal University of Technology (UTFPR). Curitiba, 2012.. This thesis proposes a method called PM-MDA for the development of Platform Models in the context of Model Driven Architecture (MDA). The PM-MDA method focuses on the development of embedded software projects based on Real-Time Operating Systems (RTOS). Additionally, this study defines a UML 2.0 Profile for Modeling Application and Platform of Embedded Software (PROAPES), which is used in the PM-MDA method. Such profile defines a set of stereotypes to generically describe Platform Models (PMs) and Platform Independent Models (PIMs). Further, extensions are defined in this profile, e.g. the PROAPESX profile, allowing the modeling of PMs into versions of the X RTOS Real-Time Kernel and associated hardware. In its turn, the PROAPES profile enables the link of a PIM to a PM, allowing these models to be entered as input attributes in a Model Transformation. In the context of MDA, this profile is a platform metamodel for building PMs, i.e., a metamodel of a family of similar platforms. In this way, a PM is used as a fundamental part in the development of embedded software in the MDA approach by providing means of obtaining platform independence. In current MDA approaches, model transformations implicitly employ PMs. As the concerns regarding the platform are not separated from the concerns related to model transformations, for each required platform there must be one or more corresponding model transformations that are configured specifically for that platform. This results in model transformation processes that are expensive and difficult to be automated. In some application domains such as embedded systems, the use of MDA is more motivating because of the heterogeneity of platforms and the complexity of these systems. The PM-MDA method, which makes use of the PROAPES profile, aims to systematize the process of creating and providing platform models separated from the model transformation process, enabling the generation of efficient and adaptable model transformations. Keywords: Model Driven Architecture (MDA). Platform Model. UML Profile. Embedded Software..

(9) LISTA DE FIGURAS Figura 1 - Exemplos de Sistemas Embarcados ......................................................................... 25 Figura 2 - Modelo de Sistemas Embarcados em três camadas ............................................... ..27 Figura 3 - Modelo de Sistemas Embarcados em sete camadas ................................................ 28 Figura 4 - Projetos por tipo de Microcontrolador ..................................................................... 31 Figura 5 - Mercado de processadores de 32 bits ...................................................................... 31 Figura 6 - Núcleo Monolítico (à esq.) e Núcleo Micronúcleo (à dir.) ...................................... 34 Figura 7 - SOs mais usados em projetos de Sistemas Embarcados .......................................... 36 Figura 8 - Exemplo de um programa usando o RTOS X Real-Time Kernel ............................. 39 Figura 9 - Modelos e Linguagens ............................................................................................. 41 Figura 10 - Visão geral das camadas M0 a M3 ........................................................................ 42 Figura 11 - Exemplo de um modelo PIM de um Sistema de Vendas (reduzido) ..................... 43 Figura 12 - Padrão Básico de Transformação de Modelos ....................................................... 49 Figura 13 - A abordagem MDA ................................................................................................ 51 Figura 14 - Classificação de diagramas da UML ...................................................................... 53 Figura 15 - Os elementos definidos no Pacote Perfil ............................................................... 54 Figura 16 - Exemplo de um perfil UML ................................................................................... 56 Figura 17 - Exemplo de uma biblioteca de modelos (model library)....................................... 57 Figura 18 - Um modelo do domínio parcial de uma linguagem específica do domínio .......... 58 Figura 19 - Padrão Recurso-Serviço ......................................................................................... 59 Figura 20 - Uso de associações para descrever as propriedades e serviços ............................. 60 Figura 21 - Exemplo do uso do padrão Resource-Service........................................................ 60 Figura 22 - Exemplo reduzido de um diagrama de classe UML .............................................. 63 Figura 23 - Principais ferramentas incluídas em TOPCASED VF ........................................... 64 Figura 24 - PROAPES e extensões inseridos na hierarquia de de metamodelagem................. 63 Figura 25 - Técnica proposta para o desenvolvimento do perfil PROAPES ............................ 69 Figura 26 - Arquitetura Geral do Modelo de Domínio baseado em RTOS .............................. 70 Figura 27 - Modelo de domínio da Aplicação .......................................................................... 71 Figura 28 - Modelo de domínio dynSwRTOS ........................................................................... 72 Figura 29 - Modelo de domínio dynDDRTOS .......................................................................... 74 Figura 30 - Modelo de domínio PMRTOS ............................................................................... 74 Figura 31 - Arquitetura geral do perfil PROAPES ................................................................... 74 Figura 32 - Perfil AMP ............................................................................................................. 77 Figura 33 - Arquitetura geral do perfil dynRTOS ..................................................................... 78 Figura 34 - Visão geral do perfil dynSwRTOS ......................................................................... 79 Figura 35 - Visão geral do perfil dynDDRTOS ........................................................................ 80 Figura 36 - Visão geral do perfil PMRTOS .............................................................................. 81 Figura 37 - Arquitetura Geral do Modelo de Domínio do RTOS X Real-Time Kernel ............ 83 Figura 38 - Modelo do domínio dos Tipos Básicos do RTOS X Real-Time Kernel ................. 84 Figura 39 - Modelo do domínio dos Tipos de Processadores do RTOS X ............................... 84 Figura 40 - Visão Geral do modelo do domínio swxCoreRTOS ............................................. 85 Figura 41 - Visão Geral do modelo do domínio swxCore........................................................ 86 Figura 42 - Visão Geral do Modelo do domínio swxSemaphore ............................................. 87 Figura 43 - Visão Geral do modelo do domínio swxPipe ........................................................ 88 Figura 44 - Visão Geral do modelo do domínio swxTimeRTOS ............................................. 88 Figura 45 - Visão Geral do modelo do domínio swxShellRTOS ............................................. 89 Figura 46 - Visão Geral do modelo do domínio ddxRTOS...................................................... 90 Figura 47 - Visão Geral do Perfil PROAPESX ......................................................................... 90.

(10) Figura 48 - Arquitetura Geral do Perfil PROAPESX................................................................ 91 Figura 49 - Visão geral da biblioteca de modelos BasicTypesX.............................................. 92 Figura 50 - Visão geral da biblioteca de modelos TypesProcessorX ....................................... 94 Figura 51 - Visão geral do perfil swxRTOS ............................................................................. 95 Figura 52 - Visão geral perfil swxCoreRTOS .......................................................................... 97 Figura 53 - Visão geral perfil swxTimeRTOS ......................................................................... 98 Figura 54 - Visão geral perfil swxShellRTOS ......................................................................... 99 Figura 55 - Visão geral perfil ddxRTOS ................................................................................ 100 Figura 56 - Exemplo usando a opção de validação de modelos no perfil PROAPESX.......... 102 Figura 57 - Exemplo usando a opção de validação de restrições no perfil PROAPESX ........ 103 Figura 58 - Exemplo do uso da opção OCL Checker no Perfil PROAPESX.......................... 103 Figura 59 - Etapas de desenvolvimento do Método PM-MDA .............................................. 107 Figura 60 - Exemplo de validação de um fragmento do PM X - eAT65 ............................... 107 Figura 61 - Exemplo usando a opção de validação de restrições no PM X - eAT55 ............. 107 Figura 62 - Exemplo usando a opção OCL Checker no PM X - eAT55 ................................ 107 Figura 63 - Visão de um fragmento do Modelo de Plataforma X - eAT55 (pacote xl) ......... 114 Figura 64 - Visão de um fragmento do PM X - eAT55 (ddlx_Atmel_devices) ..................... 115 Figura 65 - Visão de um fragmento do PM X - eLPC48 (ddlx_LPC_devices) ..................... 117 Figura 66 - Modelo de Plataforma integrado à abordagem MDA .......................................... 118 Figura 67 - Estrutura da Transformação de Modelos ............................................................. 120 Figura 68 - Passos da Transformação de Modelos PIM-to-PSM ........................................... 121 Figura 69 - Inserção do PM à transformação de modelos estáticos ....................................... 123 Figura 70 - Exemplo da integração do PM a transformação de modelos MT-PROAPES ...... 128 Figura 71 - Placa eAT55 da eSysTech ................................................................................... 135 Figura 72 - Módulo SOM eLPC48 da eSysTech .................................................................... 136 Figura 73 - Caso de estudo - Pacote de Casos de Uso Comum .............................................. 139 Figura 74 - Caso de estudo - Pacote de Casos de Uso Inicializar SA .................................... 140 Figura 75 - Caso de estudo - Pacote de Casos de Uso Gerenciar LEDs ................................ 140 Figura 76 - Caso de estudo - Pacote de Casos de Uso Gerenciar Alarme .............................. 141 Figura 77 - Caso de estudo - Pacote de Casos de Uso Gerenciar Display ............................. 141 Figura 78 - Caso de estudo - Pacote de Casos de Uso Gerenciar Menu ................................ 142 Figura 79 - Caso de estudo - Pacote de Casos de Uso Gerenciar Sensor ............................... 142 Figura 80 - Caso de estudo - Pacote de Casos de Uso Gerenciar Sirene................................ 143 Figura 81 - Caso de estudo - Pacote de Casos de Uso Gerenciar Senha ................................ 143 Figura 82 - Caso de estudo - Modelo de Sequência Enviar mensagens entre as threads ....... 146 Figura 83 - Caso de estudo - Modelo de Sequência Receber mensagens entre as threads ..... 147 Figura 84 - Caso de estudo - Modelo de Sequência Checar mensagens ................................ 148 Figura 85 - Caso de estudo - Modelo de Sequência Inicializar SA (A) ................................. 151 Figura 86 - Caso de estudo - Modelo de Sequência Inicializar SA (B) eAt55 ....................... 152 Figura 87 - Caso de estudo - Modelo de Sequência Inicializar SA (B) eLPC48 ................... 153 Figura 88 - Caso de estudo - Modelo de Sequência Emular Alarme Ativando...................... 155 Figura 89 - Caso de estudo - Modelo de Sequência Emular Sirene ....................................... 156 Figura 90 - Caso de estudo - Modelo de Sequência Emular Alarme Reagindo ..................... 157 Figura 91 - Caso de estudo - Modelo de Sequência Alterar Estado ....................................... 159 Figura 92 - Caso de estudo - Modelo de Sequência Limpar Display ..................................... 160 Figura 93 - Caso de estudo - Modelo de Sequência Mostrar Senha Incorreta ....................... 161 Figura 94 - Caso de estudo - Modelo de Sequência Mostrar Palavra eAt55 e eLPC48 ......... 162 Figura 95 - Caso de estudo - Modelo de Sequência Gerenciar Sensor................................... 164 Figura 96 - Caso de estudo - PIM do Diagrama de Classes ................................................... 165 Figura 97 - Regras de Transformação do Módulo MT-AMP................................................. 166.

(11) Figura 98 - Caso de Estudo - PSM_X_eAt55 do Diagrama de Classes ................................. 167 Figura 99 - Caso de Estudo - PSM_X_eLPC48 do Diagrama de Classes.............................. 168 Figura 100 - Arquitetura geral do RTOS X Real-Time Kernel ............................................... 208 Figura 101 - Definição de tipos de dados usados no RTOS X Real-Time Kernel .................. 210 Figura 102 - Visão geral do pacote xl .................................................................................... 211 Figura 103 - Exemplo de atribuição de valores rotulados às propriedades da classe X ......... 211 Figura 104 - Diagrama de Classes do pacote x_time ............................................................. 217 Figura 105 - Visão geral do pacote x_shell ............................................................................ 219 Figura 106 - Visão parcial da model library de drivers de dispositivos do RTOS X.............. 222 Figura 107 - Descrição (parcial) do pacote ddlx_atmel_devices ........................................... 224 Figura 108 - Descrição (completa) do pacote ddlx_atmel_devices ........................................ 225 Figura 109 - Diagrama de classes bases e classes de drivers de dispositivos Atmel ............. 225 Figura 110 - Visão parcial do pacote ddlx_lpc_devices ......................................................... 231 Figura 111 - Visão total do pacote ddlx_lpc_devices............................................................. 231 Figura 112 - Diagrama de classes bases e de classes de drivers de dispositivos LPC ........... 235.

(12) LISTA DE TABELAS Tabela 1 - Descrição dos tipos de dados da biblioteca de modelos BasicTypesX ................... 93 Tabela 2 - Informações sobre as enumerações descritas em TypesProcessorX ....................... 95 Tabela 3 - Estereótipos do perfil AMP ................................................................................... 189 Tabela 4 - Estereótipos do perfil dynSwRTOS ...................................................................... 190 Tabela 5 - Estereótipos do perfil dynDDRTOS ..................................................................... 190 Tabela 6 - Estereótipos do perfil PMRTOS ........................................................................... 190 Tabela 7 - Estereótipos do perfil swxCoreRTOS ................................................................... 190 Tabela 8 - Estereótipos do perfil swxTimeRTOS .................................................................. 196 Tabela 9 - Estereótipos do perfil swxShellRTOS................................................................... 197 Tabela 10 - Estereótipos do perfil ddxRTOS ......................................................................... 198 Tabela 11 - Descrição dos tipos de dados do pacote x_types ................................................. 209 Tabela 12 - Descrição das classes do pacote xl ...................................................................... 212 Tabela 13 - Descrição das classes do pacote x_time .............................................................. 218 Tabela 14 - Descrição das classes do pacote x_shell ............................................................. 220 Tabela 15- Descrição das classes do pacote ddlx_base_classes ............................................. 223 Tabela 16- Descrição das classes e enumerações do pacote ddlx_atmel_devices ................. 225 Tabela 17 - Descrição das classes do pacote ddlx_lpc_devices ............................................. 232 Tabela 18 - Descrição de restrições OCL – Perfil PROAPES ............................................... 236 Tabela 19 - Descrição de restrições OCL – Modelo de Plataforma ....................................... 237 Tabela 20 - Programas e arquivos de cabeçalho do Sistema de Alarme ............................... 239.

(13) LISTA DE ABREVIATURAS, SIGLAS E ACRÔNIMOS AMP API ARM ATL CISC CWM DTFs EMP ESC IDE INRIA LCD MARTE MDA MDD MDE MOF MT OCL OMG PCB PIM PM PM-MDA PROAPES PROAPESX. Application Modeling Profile Application Programming Interface Advanced RISC Machines Atlas Transformation Language Complex Instruction Set Computer Common Warehouse Metamodel Domain Task Forces Eclipse Modeling Projects Embedded System Conference Integrated Development Environment Institut National de Recherche en Informatique et en Automatique Liquid Crystal Display Modeling and Analysis of Real-Time and Embedded Systems Model Driven Architecture Model Driven Development Model Driven Engineering Meta Object Facility Model Transformation Object Constraint Language Object Management Group Printed Circuit Board Platform Independent Model Platform Model Platform Model – Model Driven Architecture Profile for modeling Application and Platform of Embedded Software Profile for modeling Application and Platform of Embedded Software for RTOS X Real-Time PSM Platform Specific Model QVT Queries / Views / Transformations (QVT) RISC Reduced Instruction Set Computer RTC Real Time Clock RTOS Real-Time Operating Systems SA Simulador de Alarme SADT Structure Analysis and Design Techniches SoC System-on-a-Chip SOM System-on-Module SRM Software Resource Modeling TOPCASED Toolkit in OPen-source for Critical Application & SystEms Development UML Unified Modeling Language VHDL VHSIC - Very High Speed Integrated Circuits - Hardware Description Language VLIW Very Long Instruction Word.

(14) SUMÁRIO 1 INTRODUÇÃO .............................................................................................. 15 1.1 CONTEXTUALIZAÇÃO .................................................................................................. 15 1.2 OBJETIVOS ....................................................................................................................... 18 1.3 MOTIVAÇÃO .................................................................................................................... 19 1.4 METODOLOGIA............................................................................................................... 21 1.5 ORGANIZAÇÃO DO TRABALHO ................................................................................. 23. 2 FUNDAMENTAÇÃO TEÓRICA ................................................................ 24 2.1 SISTEMAS EMBARCADOS ............................................................................................ 24 2.1.1 Visão Geral de Sistemas Embarcados ............................................................................. 24 2.1.2 Características de Sistemas Embarcados ......................................................................... 25 2.1.3 Arquiteturas de Sistemas Embarcados............................................................................. 26 2.1.3.1 Arquitetura de hardware .............................................................................................. 29 2.1.3.2 Arquiteturas de Processadores ..................................................................................... 30 2.1.4 Desenvolvimento de Sistemas Embarcados .................................................................... 32 2.1.5 Software Embarcado ........................................................................................................ 33 2.1.6 Sistemas Operacionais para Sistemas Embarcados ......................................................... 34 2.1.7 Núcleo Operacional X Real-Time Kernel ........................................................................ 40 2.2 ARQUITETURA DIRIGIDA A MODELOS .................................................................... 39 2.2.1 Modelos e Metamodelos .................................................................................................. 38 2.2.2 Modelo Independente de Plataforma ............................................................................... 43 2.2.3 Modelo Específico de Plataforma .................................................................................... 44 2.2.4 Modelo de Plataforma...................................................................................................... 45 2.2.4.1 Independência de Plataforma....................................................................................... 47 2.2.5 Transformação de Modelos ............................................................................................. 48 2.2.5.1 Transformação de Modelos e Modelo de Plataforma .................................................. 50 2.2.6 Mecanismos de Padronização OMG e Tecnologias Adicionais ...................................... 48 2.2.6.1 MOF ............................................................................................................................. 52 2.2.6.2 UML .............................................................................................................................. 52 2.2.6.3 Perfil UML.................................................................................................................... 53 2.2.6.4 Biblioteca de Modelos (Model Library) ....................................................................... 56 2.2.6.5 Elaboração de Perfis UML .......................................................................................... 57 2.2.6.6 Modelo do domínio da Plataforma .............................................................................. 58 2.2.6.7 OCL .............................................................................................................................. 61 2.2.7 Ferramenta MDA - TOPCASED ..................................................................................... 63 2.2.7.1 Framework de Validação TOPCASED - VF ................................................................ 63 2.3 CONCLUSÕES DO CAPÍTULO ...................................................................................... 65. 3 PERFIL PROAPES ........................................................................................ 66 3.1 VISÃO GERAL DO PERFIL PROAPES .......................................................................... 66 3.2 ETAPAS PARA A DEFINIÇÃO DO PERFIL PROAPES ................................................ 68 3.2.1 Definição e Agrupamento de Conceitos .......................................................................... 69 3.2.2 Especificação do Modelo do domínio ............................................................................. 69 3.2.2.1 Modelo do domínio Estático da Aplicação - AMP ....................................................... 70 3.2.2.2 Modelo do domínio Dinâmico da Aplicação - dynRTOS ............................................. 71 3.2.2.3 Modelo do domínio da Plataforma............................................................................... 72 3.2.3 Especificação do Perfil PROAPES .................................................................................. 73 3.2.3.1 Perfil AMP .................................................................................................................... 76.

(15) 3.2.3.2 Perfil dynRTOS ............................................................................................................. 77 3.2.3.3 Perfil PMRTOS ............................................................................................................. 80 3.2.4 Validação do Perfil PROAPES ........................................................................................ 81 3.3 PERFIL PROAPESX .......................................................................................................... 82 3.3.1 Definição e Agrupamento de Conceitos do perfil PROAPESX ...................................... 82 3.3.2 Especificação do Modelo do domínio do perfil PROAPESX ........................................ 83 3.3.2.1 Pacote BasicTypesX ..................................................................................................... 83 3.3.2.2 Pacote TypeProcessorX................................................................................................ 84 3.3.2.3 Modelo do domínio da Plataforma - swxRTOS ............................................................ 84 3.3.3 Especificação do perfil PROAPESX .............................................................................. 90 3.3.3.1 Biblioteca de Modelos BasicTypesX ............................................................................ 92 3.3.3.2 Biblioteca de Modelos TypeProcessorX ....................................................................... 93 3.3.3.3 Perfil swxRTOS ............................................................................................................ 95 3.3.4 Validação do perfil PROAPESX ................................................................................... 101 3.4 CONCLUSÕES DO CAPÍTULO .................................................................................... 104. 4 MÉTODO PM-MDA .................................................................................... 106 4.1 VISÃO GERAL DO MÉTODO PM-MDA ...................................................................... 106 4.2 ETAPAS PARA A CONSTRUÇÃO DO PM USANDO O MÉTODO PM-MDA ......... 107 4.2.1 Seleção do RTOS ........................................................................................................... 107 4.2.2 Definição da Arquitetura de Hardware e Processadores .............................................. 108 4.2.3 Análise da API do RTOS Selecionado ........................................................................... 108 4.2.4 Construção do Modelo de Plataforma RTOS ................................................................. 108 4.2.5 Validação do Modelo de Plataforma RTOS ................................................................... 109 4.2.5.1 Validação do Modelo de Plataforma RTOS X Real-Time Kernel .............................. 109 4.3 EXEMPLIFICAÇÃO DO USO DO MÉTODO PM-MDA .............................................. 112 4.3.1 Aplicação do método PM-MDA ao PM RTOS X Real-Time Kernel X – eAt55 ............ 112 4.3.2 Aplicação do método PM-MDA ao PM RTOS X Real-Time Kernel X – eLPC48......... 116 4.4 INTEGRAÇÃO DO MODELO DE PLATAFORMA À MDA ....................................... 118 4.4.1 Integração do PM à MDA usando Modelos Estáticos ................................................... 119 4.4.1.1 Criação do PIM .......................................................................................................... 119 4.4.1.2 Criação do PM ........................................................................................................... 119 4.4.1.3 Transformação de Modelos Estáticos ........................................................................ 120 4.4.1.4 Exemplificação da integração do PM à MDA usando Modelos Estáticos................. 121 4.4.2 Integração do PM à MDA usando Modelos Dinâmicos ................................................ 125 4.4.2.1 Criação do PIM .......................................................................................................... 125 4.4.2.2 Criação do PM ........................................................................................................... 126 4.4.2.3 Transformação de Modelos de Modelos Dinâmicos .................................................. 126 4.4.2.4 Exemplificação da integração do PM à MDA usando Modelos Dinâmicos .............. 127 4.5 CONCLUSÕES DO CAPÍTULO .................................................................................... 129. 5 CASO DE ESTUDO ..................................................................................... 131 5.1 CASO DE ESTUDO – SISTEMA EMBARCADO ......................................................... 131 5.1.1 Objetivos do Caso de Estudo ......................................................................................... 131 5.1.2 Descrição do Simulador de Alarme ............................................................................... 132 5.1.3 Organização do Software ............................................................................................... 132 5.1.4 Aplicação do método PM-MDA ao SA ......................................................................... 134 5.1.4.1 Seleção de RTOS para o SA ....................................................................................... 134 5.1.4.2 Definição da Arquitetura de Hardware e de Processadores para o SA .................... 135 5.1.4.3 Análise da API do RTOS selecionado para o SA ....................................................... 136 5.1.4.4 Construção do Modelo de Plataforma para o SA ...................................................... 136 5.1.5 Integração do PM à MDA e exemplificação por meio do SA ....................................... 137.

(16) 5.1.5.1 Modelos de Sequência para Modelos de Casos de Uso Comum................................ 143 5.1.5.2 Modelos de Sequência para Modelos de Casos de Uso Inicializar SA ...................... 148 5.1.5.3 Modelos de Sequência para Modelos de Casos de Uso Gerenciar LEDs.................. 154 5.1.5.4 Modelos de Sequência para Modelos de Casos de Uso Gerenciar DISPLAY ........... 158 5.1.5.5 Modelos de Sequência para Modelos de Casos de Uso Gerenciar SENSOR ............ 163 5.1.5.6 Modelos de Classes do SA .......................................................................................... 163 5.2 CONCLUSÕES DO CAPÍTULO ................................................................................... 168. 6 CONCLUSÕES ............................................................................................ 171 6.1 RESUMO DA PESQUISA............................................................................................... 171 6.2 PRINCIPAIS CONTRIBUIÇÕES ................................................................................... 173 6.3 DIFICULDADES E LIMITAÇÕES ................................................................................ 175 6.4 TRABALHOS FUTUROS ............................................................................................... 175. REFERÊNCIAS .............................................................................................. 177 APÊNDICE A - Descrição de Estereótipos do perfil PROAPES ................ 189 APÊNDICE B - Modelo de Plataforma RTOS X Real-Time Kernel ......... 208 APÊNDICE C - Conjunto de Restrições OCL para o Perfil PROAPESX . 238 APÊNDICE D - Conjunto de Restrições OCL para o PM........................... 237 APÊNDICE E - Código Fonte de Software Embarcado SA ........................ 239 APÊNDICE F - Survey .................................................................................... 240.

(17) 15. 1 INTRODUÇÃO Este capítulo apresenta uma visão geral dessa pesquisa de doutorado por meio da descrição do tema do trabalho, do contexto no qual este tema está inserido, além dos principais problemas envolvidos que representam as questões de base do trabalho. Neste capítulo, também são apresentados os objetivos gerais do trabalho e os objetivos específicos a serem alcançados, bem como a motivação para a sua realização e a metodologia usada para desenvolvê-lo. Por fim, apresenta-se a organização dos capítulos do documento.. 1.1. CONTEXTUALIZAÇÃO. A Engenharia de Software, por meio de métodos, ferramentas e procedimentos, busca constantemente melhorar a qualidade dos produtos de software e aumentar a produtividade no processo de desenvolvimento de software (PRESSMAN, 2006). Assim, seu objetivo é atender à crescente demanda por sistemas de software, cada vez mais complexos, nos diversos segmentos da sociedade. Atualmente, apesar dos avanços na área da Engenharia de Software, ainda existem muitos problemas relacionados ao desenvolvimento de software. No entanto, o software, além de ser confiável, deve operar em ambientes computacionais complexos, tais como sistemas embarcados em tempo real, e deve ser adaptado a mudanças ocorridas nos ambientes operacionais (HUTCHINSON et al., 2011). Isso se deve às tecnologias usadas, que se tornaram significativamente mais complexas nos últimos anos, e também porque essas tecnologias mudam mais rapidamente do que os negócios para os quais as mesmas oferecem suporte (UHL, 2003). Para contribuir na solução desses problemas, surgiu a abordagem Model Driven Engineering (MDE), que se refere ao uso sistemático de modelos como artefatos principais da engenharia ao longo de todo o ciclo de desenvolvimento de software. O termo foi inicialmente proposto por Kent (2002), derivado da Model Driven Architecture (MDA), uma proposta do Object Management Group (OMG) (OMG, 2001; OMG, 2003). A MDE envolve pesquisas atuais relacionadas a técnicas gerativas e transformacionais em Engenharia de Software, Engenharia de Sistema e Engenharia de Dados. A MDE é uma abordagem geral de desenvolvimento dirigido a modelos, que inclui, mas não se limita à MDA (SCHMIDT, 2006)..

(18) 16. A MDA é a iniciativa de MDE mais conhecida e adotada atualmente (RICCOBENE; SCANDURRA, 2009). A MDA usa uma coleção de modelos, linguagens de especificação padronizadas e um conjunto de ferramentas especializadas para definir precisamente os requisitos de sistemas e realizar transformações entre esses modelos. Adicionalmente, a Model Driven Development (MDD), uma abordagem derivada da MDA, também se refere ao desenvolvimento dirigido a modelos (ATKINSON; KÜHNE, 2003; MELLOR, 2003). Na MDA, um modelo é usado para a geração de outro modelo. Esses modelos podem estar no mesmo nível de abstração ou em níveis de abstração diferentes. Modelos mais abstratos estão mais distantes das particularidades da plataforma computacional, ou seja, das tecnologias que oferecem suporte a sua execução como o hardware e sistema operacional, uma vez que os modelos menos abstratos estão mais próximos das especificações da plataforma. Desse modo, a MDA promove o uso de modelos como principais artefatos em todas as fases de desenvolvimento de software (SELIC, 2003). A abordagem MDA representa um interessante recurso no desenvolvimento de software, pois oculta detalhes técnicos que seriam irrelevantes para a definição de funcionalidade (em alto nível) de um componente de software. Desse modo, o engenheiro de software pode se concentrar de maneira mais produtiva no desenvolvimento de modelos de mais alto nível de abstração. Entretanto, vários aspectos em MDA necessitam ser mais investigados, de forma que essa abordagem de desenvolvimento se torne mais efetiva. Entre esses aspectos, destacam-se a independência de plataforma, a transformação de modelos e ferramentas para MDA. Dentre esses aspectos, o abordado nesta tese está relacionado à questão de projetos de software com independência de plataforma. A abordagem de desenvolvimento de MDA envolve a construção de um modelo independente de plataforma (Platform Independent Model – PIM), a especificação de um Modelo de Plataforma (Platform Model – PM) baseado na seleção de uma plataforma particular para o sistema e a transformação de um modelo PIM para um modelo específico de plataforma (Platform Specific Model – PSM) (OMG, 2003). Plataforma, em MDA, constitui-se de um conjunto de tecnologias que provê um conjunto coerente de funcionalidades por meio de interfaces e padrões de uso especificados, na qual um subsistema dependente da plataforma pode utilizá-la, sem preocupar-se com detalhes de como as funcionalidades fornecidas pela plataforma foram implementadas (OMG, 2003)..

(19) 17. Por sua vez, um modelo de plataforma provê um conjunto de conceitos técnicos, que representam as partes e os serviços de uma plataforma. Além disso, esse modelo provê conceitos representando os diferentes tipos de elementos que podem ser usados na especificação do uso da plataforma por uma aplicação (OMG, 2003). Os modelos de plataforma possuem um papel fundamental em MDA e são empregados nas transformações de modelos independentes em modelos dependentes de plataforma. A transformação de modelos pode ser caracterizada como a conversão de um modelo de mais alto nível para um modelo de mais baixo nível de abstração, considerando um conjunto de regras bem definidas (DUBE; DIXIT, 2012). A maioria das pesquisas em MDA define transformações de modelos que empregam implicitamente as características de modelos de plataforma (TRATT, 2006; KARSAI et al., 2008; JEON et al., 2009). Como os interesses referentes à plataforma não estão separados dos interesses das transformações de modelos, para cada plataforma requerida deve existir uma ou mais transformações de modelos correspondentes, que são configuradas, especificamente, para aquela plataforma. O resultado disso é o custo elevado e maior complexidade dos processos de transformações de modelos (CHEHADE et al., 2011). Esta pesquisa de doutorado compreende o estudo e a proposição de alternativas para desacoplar as especificações das plataformas do processo de transformação de modelos de software. Desse modo, foi proposto o método PM-MDA para a construção de modelos de plataforma separados e independentes das regras de transformação de modelos definidas no contexto da abordagem MDA. Além disso, como parte do método proposto, foi definido o perfil denominado Profile for modeling Application and Platform of embedded Software (PROAPES) e extensões tal como o perfil PROAPESX, para a modelagem de uma família de plataformas similares para o desenvolvimento de software embarcado baseado no RTOS X Real-Time Kernel e seus hardware associados. Em alguns domínios de aplicação, como sistemas embarcados, o desenvolvimento de software é uma atividade mais desafiante, pois existem certas características que devem ser cuidadosamente consideradas no projeto, tais como: restrições referentes à concorrência, tempo-real e uso de recursos, além da ampla diversidade e heterogeneidade de plataformas. Pesquisas no contexto da MDA para sistemas embarcados, envolvendo questões relativas às características acima citadas, ainda são necessárias para proporcionar um aumento significativo, em termos de qualidade e produtividade, no processo de desenvolvimento de software para tais sistemas..

(20) 18. Com relação ao mercado brasileiro de desenvolvimento de software embarcado, constata-se que a maioria dos desenvolvedores compreende o valor de se utilizar a modelagem para o desenvolvimento de software, embora, na prática, a mesma seja utilizada de forma reduzida. A linguagem Unified Modeling Language (UML) é a mais utilizada dentre as linguagens de modelagem, porém seu uso destina-se, principalmente, à documentação de projetos. Os principais problemas que impedem o uso de modelagem são: prazo reduzido para o desenvolvimento de sistemas, número reduzido de pessoas nas empresas que conhecem modelagem e acesso reduzido a ferramentas de modelagem (AGNERc et al., 2012). Além disso, no Brasil, os desenvolvedores mais experientes de software embarcado são os mais satisfeitos com o uso de modelagem no desenvolvimento de software embarcado. A maioria dos desenvolvedores que utilizam abordagens dirigidas a modelos confirmam as principais vantagens de seu uso tais como: aumento na produtividade de desenvolvimento de software, aumento na qualidade de software e maior facilidade na manutenção de software e portabilidade para novas plataformas (AGNERc et al., 2012). De outro modo, constatou-se que a maioria dos desenvolvedores não possui conhecimento suficientemente maduro sobre questões chave em abordagens dirigidas a modelos que se referem à transformação de modelos, geração de código e uso de modelos em testes (AGNERc et al., 2012).. 1.2. OBJETIVOS. O objetivo geral deste trabalho de pesquisa é a definição de um método denominado PM-MDA para a construção de modelos de plataforma no contexto da abordagem MDA. Esse método tem como foco o desenvolvimento de projetos de software embarcado, baseados em Sistemas Operacionais em Tempo-Real (Real-Time Operating Systems – RTOS). Assim, o método PM-MDA pode ser usado como um guia para engenheiros de software durante a elaboração de projetos de software embarcado baseado em RTOS na abordagem MDA. Os principais propósitos do método são sistematizar o processo de criação e disponibilização de modelos de plataforma separados dos processos de transformações de modelos PIM em modelos PSM e possibilitar a geração de processos eficientes de transformações de modelos. Os objetivos específicos deste trabalho de pesquisa são: •. Propor o perfil PROAPES, como parte do método proposto, responsável pela modelagem de plataforma e de aplicação de RTOS;.

(21) 19 •. Definir extensões do perfil PROAPES, tal como o perfil PROAPESX, apresentado nesta pesquisa, que permite especificar, de forma abstrata, modelos de plataforma usando um conjunto de serviços oferecidos pelo RTOS X RealTime Kernel para arquitetura Advanced RISC Machines (ARM);. •. Realizar a ligação entre o PIM e o PM, por meio de estereótipos definidos no perfil PROAPES, permitindo que os modelos PIM e PM sejam inseridos como parâmetros de entrada em um processo de transformação de modelos;. •. Realizar um caso de estudo prático de aplicação do método PM-MDA a fim de avaliar o método, o perfil PROAPES e sua extensão o perfil PROAPESX, assim como a integração do PM gerado à abordagem MDA;. •. Realizar a validação do perfil PROAPES e sua extensão perfil PROAPESX, além dos modelos de plataforma gerados por meio do PM-MDA, usando uma estratégia de validação definida por meio do framework de validação TOPCASED-VF; e. •. Realizar e apresentar os resultados de um survey, intitulado “Estudo da utilização de modelagem no desenvolvimento de software para sistemas microprocessados (software embarcado)”, visando fundamentar as premissas da pesquisa e contribuir com dados estatísticos sobre o uso de modelagem de software por meio da UML e MDA no desenvolvimento de sistemas embarcados.. 1.3. MOTIVAÇÃO. A dependência de plataforma é um problema constante na Engenharia de Software, pois restringe a utilização dos elementos do sistema à arquitetura para a qual foi implementada (OMG, 2003). Para resolver esse problema, buscam-se formas de desenvolver aplicações que sejam mais independentes de plataformas e que possam ser transformadas para plataformas específicas. Apesar dos esforços na busca de independência de plataforma, o problema ainda persiste (OMG, 2003). Devido às dificuldades de se alcançar maior portabilidade, o projeto e a elaboração dos sistemas continuam sendo feitos com foco em uma determinada arquitetura. Esse problema aumenta para alguns aplicativos de domínios específicos, como projetos de sistemas embarcados baseados em Sistemas Operacionais em Tempo-Real (Real-Time Operating Systems – RTOS), pois esses sistemas são complexos e heterogêneos. O suporte.

(22) 20. oferecido pela MDA para o desenvolvimento de sistemas embarcados baseados em RTOS é reduzido. A MDA foca, principalmente, em plataformas-alvo baseadas em middleware, tais como: EJB, .NET, CORBA e serviços Web (MAENG et al., 2006). Essas plataformas permitem que aplicações sejam projetadas de forma independente (ou pouco dependente) do middleware utilizado. Por sua vez, na área de sistemas embarcados, as plataformas alvo se diferenciam pelas arquiteturas de hardware e pelo firmware (incluindo RTOS), além do middleware. Assim, a modelagem de plataforma tem mais impacto nas questões de independência de plataforma na área de sistemas embarcados (BECKER et al., 2010). A independência de plataforma aumenta a produtividade no desenvolvimento de software, e, por esta razão a MDA define uma abordagem para o processo de desenvolvimento de software baseado na construção de modelos de alto nível de abstração e independentes de plataformas (KLEPPE et al., 2003; FRANCE; RUMPE, 2007; VALLECILLO, 2008). Atualmente, a maioria das pesquisas em MDA tem concentrado esforços em “transformações” (BIEHL, 2010; YUE et al., 2011). Por outro lado, interesses relacionados à plataforma, aos modelos de plataforma e à independência de plataforma têm recebido menor atenção. Existem algumas pesquisas relacionadas à definição de modelos de plataformas em MDA, porém não são aplicadas ao desenvolvimento de software embarcado baseado em RTOS (KUKKALA et al., 2005; SELIC, 2007; SANDRIESER et al., 2011). Uma pesquisa que está centrada exatamente em independência de plataforma para sistemas embarcados é a que se refere ao perfil Modeling and Analysis of Real-Time and Embedded Systems (MARTE). Esta pesquisa propõe, inclusive, um subperfil denominado Software Resource Modeling (SRM). Este subperfil fornece artefatos detalhados e recursos de modelagem de plataformas para o desenvolvimento de software embarcado baseado em diferentes RTOS (OMGc, 2011). O perfil MARTE, entretanto, oferece uma modelagem de plataforma extremamente generalista, o que torna o seu emprego muito complexo. Existem inúmeros estereótipos e valores rotulados que acabam gerando confusão ao utilizador. Existem, também, vários estereótipos redundantes e, assim, um mesmo elemento de modelo pode ser anotado com estereótipos diferentes que possuem a mesma semântica. Devido a sua extensão e complexidade, o emprego do perfil pode ser um desafio para os desenvolvedores (JENSEN, 2009; SILVESTRE, 2012). A principal razão para estas dificuldades com o perfil MARTE está no fato dele ter sido proposto para cobrir todas as possibilidades de diferentes plataformas em sistemas embarcados, o que o tornou demasiadamente abrangente e generalista..

(23) 21. Por sua vez, o perfil PROAPES proposto nesta pesquisa de doutorado foca a modelagem de uma família de plataformas similares, desse modo, é mais fácil construir modelos de plataformas, pois as plataformas consideradas dentro de um modelo são variações dentro de uma mesma família de versões de um RTOS e hardware associados. Desse modo, obtêm-se um conjunto de conceitos reduzidos, fácil de ser compreendido e utilizado para realizar a modelagem das plataformas. Além disso, torna-se mais simples a construção das transformações de modelos, uma vez que as regras de transformação serão mais fáceis de serem construídas. Considera-se, também, nesta pesquisa que raramente uma aplicação concebida para uma dada família de plataformas seria migrada para outra família distinta, pois em sistemas embarcados, geralmente o software está vinculado a uma determinada configuração de hardware. Portanto, uma das principais motivações para este trabalho é a necessidade existente da definição de métodos para auxiliar a construção de modelos de plataforma independentes do processo de transformação de modelos. Um dos principais benefícios do método PM-MDA é possibilitar o desenvolvimento de aplicações em software embarcado baseado em RTOS mais independentes de plataforma. No contexto da MDA, isso resultará em processos de transformações de modelos eficientes e adaptáveis a uma família de plataformas similares em sistemas embarcados.. 1.4. METODOLOGIA. A abordagem metodológica proposta neste trabalho de pesquisa foi baseada na adaptação de alguns conceitos definidos em metodologias baseadas em evidências para o desenvolvimento e introdução de tecnologias de software (SHULL et al., 2001; MAFRA et al., 2006). Essas metodologias são divididas em duas etapas principais, que são descritas a seguir: •. Definição inicial da tecnologia: realizar revisões sistemáticas, de tal modo que a definição da nova tecnologia seja baseada em evidências definidas na literatura (MAFRA et al., 2006);. •. Refinamento da tecnologia: avaliar a viabilidade da tecnologia proposta, desde a sua concepção até a sua utilização na indústria, usando essa avaliação para propor alterações e melhorias. Para tal, são realizados: estudos de viabilidade, estudos de.

(24) 22. observação e estudos de caso (ciclo de vida completo da tecnologia e no contexto industrial) (SHULL et al., 2001). As etapas realizadas no desenvolvimento desta tese foram: revisão bibliográfica, revisão sistemática, definição da proposta, avaliação e redação, conforme descrição a seguir. Na fase de refinamento da tecnologia não foi possível avaliar a viabilidade do método proposto, pois esta análise ultrapassava o escopo da pesquisa. 1. Revisão bibliográfica: inclui o estudo e a descrição de conceitos relacionados aos principais temas desta tese, que envolve Sistemas Embarcados e Arquitetura Dirigida a Modelos; 2. Revisão sistemática: nesta etapa foi realizado um estudo aprofundado dos conceitos referentes a desenvolvimento dirigido a modelos; construção e definição de modelos de plataforma; UML; perfil UML; Object Constraint Language (OCL); perfis UML definidos para software embarcado baseado em RTOS; desenvolvimento de software embarcado baseado em RTOS que utiliza código; e, principalmente, desenvolvimento de software embarcado baseado em RTOS dirigido a modelos; 3. Desenvolvimento de método de pesquisa do tipo levantamento (survey): esta etapa envolveu a realização de um survey denominado “Estudo da utilização de modelagem no desenvolvimento de software para sistemas microprocessados (software embarcado)”. Este survey visou à coleta de dados de empresas desenvolvedoras de software embarcado para identificar questões relacionadas ao uso da modelagem, por meio da UML e MDA, na construção de software embarcado; 4. Definição da proposta: após realizar as etapas anteriores, foi possível definir a elaboração do perfil PROAPES, assim como a extensão do perfil denominado PROAPESX, para a construção de modelos de plataforma e aplicação de software embarcado baseado em RTOS. Além disso, foi desenvolvido um método para a criação de modelos de plataforma de software embarcado baseado em RTOS no contexto da abordagem MDA; 5. Avaliação: nesta fase foi construído um caso de estudo para a avaliação do perfil e do método proposto. O caso de estudo desenvolvido refere-se a um sistema de alarme desenvolvido para o RTOS X Real-Time Kernel e plataformas ARM. Além disso, foi realizada a validação do perfil PROAPES e sua extensão, o perfil PROAPESX, assim como a validação dos modelos de plataforma. Essa validação foi realizada por meio da ferramenta TOPCASED VF, desse modo foi realizada a verificação sintática e a verificação semântica estática dos modelos definidos nesta pesquisa; e.

(25) 23. 6. Redação: nesta fase foi realizada a elaboração e submissão de artigos. A escrita do documento de qualificação, assim como a escrita do documento da tese.. 1.5. ORGANIZAÇÃO DO TRABALHO. Este documento está organizado em seis capítulos. O Capítulo 2 descreve a fundamentação teórica deste trabalho. Inicialmente, é apresentado um resumo sobre o desenvolvimento de sistemas embarcados e, em seguida, é abordada a contextualização de Model Driven Architecture (MDA). No Capítulo 3 é descrito o perfil PROAPES e sua extensão, denominado perfil PROAPESX. Nesse capítulo são descritas, detalhadamente, as etapas para a definição dos perfis. O Capítulo 4 descreve e exemplifica o método PM-MDA. São apresentadas as etapas para a sua construção e a sua integração à abordagem MDA. O Capítulo 5 apresenta o desenvolvimento de um caso de estudo de um sistema embarcado baseado no RTOS X Real-Time Kernel e na plataforma ARM. Por fim, no Capítulo 6 são apresentadas as conclusões desta tese de doutorado. O Apêndice A apresenta a descrição dos estereótipos do perfil PROAPES e do perfil PROAPESX. Por sua vez, o Apêndice B ilustra e descreve o modelo de plataforma desenvolvido para o RTOS X Real-Time Kernel. Os Apêndices C e D descrevem as restrições definidas para validar o perfil PROAPESX e modelos de plataforma, respectivamente. O Apêndice E apresenta um breve resumo sobre o código-fonte desenvolvido para o caso de estudo do sistema Simulador de Alarme. O Apêndice F apresenta um breve resumo referente ao desenvolvimento do survey intitulado “Estudo da utilização de modelagem no desenvolvimento de software para sistemas microprocessados (software embarcado)”..

(26) 24. 2 FUNDAMENTAÇÃO TEÓRICA Neste capítulo é apresentada a fundamentação teórica desta pesquisa de doutorado. Inicialmente, é apresentado um resumo sobre sistemas embarcados. Em seguida, são descritos os conceitos relacionados à Model Driven Architecture (MDA) e, por fim, são apresentadas as conclusões do capítulo.. 2.1. SISTEMAS EMBARCADOS. O uso intensivo e a crescente complexidade de sistemas embarcados exigem a aplicação de processos e técnicas de engenharia de software no desenvolvimento de software embarcado. O desenvolvimento de software embarcado segue os mesmos princípios de desenvolvimento de outros sistemas de computação, porém, possui diversas particularidades que devem ser consideradas. A seguir, apresenta-se, uma visão geral de sistemas embarcados e discutem-se especificidades do desenvolvimento de software para este tipo de plataforma.. 2.1.1. Visão Geral de Sistemas Embarcados Sistema embarcado pode ser definido como uma combinação de hardware e. software, bem como outros eventuais componentes mecânicos, projetado para executar um número limitado de funções. Geralmente, um sistema embarcado consiste em uma parte de um sistema ou produto maior ao qual se integra e controla (WOLF, 2001). Frequentemente, sistemas embarcados são complexos e consistem de várias tecnologias que estão conectadas internamente e se comunicando. Aplicações típicas desse tipo de sistema incluem desde telefones celulares e equipamentos eletrônicos de uso doméstico, a dispositivos complexos, como sistemas de auxílio médico, sistemas de controle de aeronaves ou industriais (CONTI et al., 2005). A Figura 1 ilustra alguns exemplos de sistemas embarcados..

(27) 25. Sistemas Embarcados. Smartphone. Máquina Fotográfica. GPS. Aviônica. Figura 1 - Exemplos de Sistemas Embarcados. O sucesso no desenvolvimento de um sistema embarcado está associado a alguns fatores: aumento da produtividade e da qualidade e redução do tempo de desenvolvimento, ao aplicar tecnologias de engenharia de software apropriadas (GRAAF, 2003). Porém, esses sistemas são multidisciplinares sendo compostos por subsistemas de software e hardware e, geralmente, envolvem outras áreas do conhecimento como eletrônica, elétrica e mecânica. Desse modo, os conceitos de engenharia de software devem ser adaptados para o desenvolvimento desse tipo de sistema. A seguir são descritos conceitos, características e considerações sobre o desenvolvimento de sistemas embarcados.. 2.1.2. Características de Sistemas Embarcados As seguintes características são comuns aos sistemas embarcados ( KOPETZ, 1997;. WOLF, 2001; BERGER, 2002; DOUGLASS, 2004; CONTI et al., 2005; MARWEDEL, 2006; STADZISZ; RENAUX, 2007): •. Interface com dispositivos: sistemas embarcados são conectados a ambientes físicos e interagem com os mesmos usando sensores e atuadores. O objetivo é usar sensores para coletar informações e atuadores para executar as ações.. •. Segurança e tolerância a falhas: embora alguns sistemas embarcados operem em produtos com baixo risco, em caso de defeito, como em um aparelho de DVD, também podem operar em ambientes nos quais os impactos de um.

(28) 26. defeito podem ser graves, como em sistemas de controle de aeronaves ou sistemas médicos. •. Recursos limitados: vários produtos que integram sistemas embarcados são projetados sob restrições de espaço e peso, por serem produtos portáteis ou produtos que são conectados a sistemas maiores com limitações dimensionais. Muitas vezes, esses produtos têm restrições de custos relacionadas à produção em grande escala devido à forte concorrência industrial. Consequentemente, aplicações. embarcadas. normalmente. são. executadas. em. plataformas. compactas, com memória reduzida, processadores de menor capacidade e envolvendo pequeno consumo de energia. Assim sendo, o uso eficiente dos recursos computacionais é obrigatório para obter a melhor relação custobenefício. •. Restrições temporais: muitos sistemas embarcados interagem com o ambiente e suas operações estão condicionadas a serem realizadas em um intervalo de tempo preciso. Os sistemas computacionais que operam sob restrições temporais são denominados sistemas em tempo real (real-time systems). Quando existe, o sistema operacional é responsável por assegurar um comportamento previsível de execução da aplicação para permitir uma garantia de desempenho necessário. Quando não se emprega um sistema operacional esta garantia recai (totalmente) sobre o desenvolvedor em relação à aplicação.. •. Comportamento Dinâmico: é comum que sistemas embarcados usem múltiplas tarefas simultâneas que interagem entre si e concorrem para o uso de recursos compartilhados. O emprego de recursos de concorrência aumenta em muito a complexidade do software.. A combinação de características em tempo-real e tarefas com comportamento dinâmico, aliada a restrições de custo e recursos, resulta em novas particularidades relacionadas aos sistemas embarcados. Essas particularidades devem ser tratadas no projeto de tais sistemas, em diferentes níveis arquiteturais.. 2.1.3. Arquiteturas de Sistemas Embarcados A arquitetura de um sistema envolve a descrição e a estruturação de seus. componentes e os relacionamentos entre esses componentes. Ao considerar sistemas.

(29) 27. embarcados, a arquitetura desses sistemas pode ser dividida em três partes ou camadas: 1ª camada - Hardware embarcado que inclui o processador e dispositivos externos; 2ª camada: Sistema operacional embarcado; e 3ª camada - Software Embarcado, conforme ilustra a Figura 2 (NOERGAARD, 2005; GAI-NING; YONG-FENG, 2011). Porém, para ser utilizado em sistemas embarcados mais complexos é necessário refinar o modelo de três camadas.. Figura 2 - Modelo de Sistemas Embarcados em três camadas Fonte: Adaptado de GAI-NING; YONG-FENG, 2011 (2011). Em (GÓES; RENAUX, 2006) foi proposto um modelo de sete camadas, ilustrado na Figura 3. Segundo tal modelo, há a camada de hardware e outras sobre a mesma. Nesse âmbito, na camada de hardware, particularmente, ocorre a execução do sistema. Porém, seria inviável, ou seja, ineficiente e moroso, desenvolver sistemas tendo como base apenas as portas lógicas disponíveis no hardware. Desse modo, ao serem construídos níveis de abstração sobre o hardware, o desenvolvimento do sistema torna-se mais ágil e confiável. As camadas componentes do modelo são descritas a seguir: 1. Hardwired-HW: camada dos dispositivos físicos, na qual os sinais elétricos são comandados por dispositivos semicondutores para realizar uma determinada atividade. 2. Softwired-HW: camada de software armazenada em dispositivos lógicos programáveis. A programação destes dispositivos é tipicamente realizada usando a linguagem VHDL (VHSIC - Very High Speed Integrated Circuits Hardware Description Language) (ENGEL; SPINCZYK, 2008). 3. Low-Level Device Drivers: camada do software básico que interage diretamente com os dispositivos de hardware das duas camadas inferiores. As camadas superiores não acessam diretamente os dispositivos de hardware, mas sempre por meio dos serviços oferecidos pelos drivers de dispositivos (device drivers)..

(30) 28. Figura 3 - Modelo de Sistemas Embarcados em sete camadas Fonte: Adaptado de Góes;Renaux (2006). 4. Núcleo Operacional: também denominado kernel ou RTOS (Real-Time Operating System), tem como objetivo principal implementar o gerenciamento do sistema de concorrência, interrupções e temporização. Atualmente é comum o uso de uma estrutura de núcleo operacional denominada micronúcleo (microkernel). Essa estrutura consiste de um módulo central (o micronúcleo), responsável pelo gerenciamento e escalonamento de tarefas, de memória, de comunicação entre tarefas e de serviço de temporização, enquanto as demais funcionalidades do núcleo operacional são implementadas em módulos de software externos ao micronúcleo. 5. Protocolos: camada de software que implementa o controle do tráfego de informações de forma estruturada sobre os canais de comunicação disponíveis (Ethernet, USB, RS-232, RS-485, GPRS, etc.). Essa estrutura define um padrão de comunicação que permite a interoperabilidade dos sistemas. Tal estrutura está definida na forma de protocolos padronizados que definem tanto o formato dos.

(31) 29. pacotes de dados a serem transmitidos como a forma de interação entre os equipamentos de comunicação. 6. Serviços: camada que implementa módulos de software reusados com frequência em diversos sistemas embarcados, relacionados a funcionalidades maiores como sistemas de arquivos. 7. Software de Aplicação: camada de software que implementa a funcionalidade específica de um determinado sistema embarcado. Um aspecto importante que deve ser observado é que os sistemas embarcados construídos seguindo o modelo de sete camadas visam o uso de módulos de hardware e software, previamente desenvolvidos e testados, reduzindo o esforço de desenvolvimento nas camadas 2 (Softwired-HW) e 7 (Software de Aplicação).. 2.1.3.1 Arquitetura de hardware A padronização da arquitetura de hardware em sistemas embarcados é extremamente difícil. Isso ocorre devido à dependência existente entre o hardware e a aplicação do sistema embarcado e à existência de outras exigências desse sistema, tais como: desempenho, robustez e confiabilidade. De forma geral, a arquitetura de hardware de um sistema embarcado inclui o processador, memória de escrita e leitura (ex. RAM), memória não volátil (ex. Flash) e um conjunto de dispositivos periféricos que permitem o interfaceamento deste sistema com seus usuários e com os demais sistemas (STADZISZ; RENAUX, 2007). Atualmente, já é possível integrar todo o hardware de um sistema em um único circuito. integrado,. denominado. System-on-a-Chip. (SoC).. Em. outras. situações,. particularmente, quando o produto não tem volume suficiente para o desenvolvimento de um circuito integrado dedicado, utiliza-se um System-on-Module (SOM) que consiste em um módulo de hardware (placa de circuito impresso com componentes eletrônicos) que implementa a funcionalidade comum a muitos sistemas embarcados (processador, memória e periféricos de uso mais frequente). Um SOM, combinado a um circuito que implementa interfaces específicas, forma então o hardware do sistema embarcado..