Método de desenvolvimento dirigido a modelos para rede de sensores sem fio

(1)

DE AUTOMAC¸ ˜AO E SISTEMAS

Andr´e Ruza Paulon

M ´ETODO DE DESENVOLVIMENTO DIRIGIDO A MODELOS PARA REDES DE SENSORES SEM FIO

Florian´opolis 2015

(2)

(3)

Tese submetida ao Programa de P´ os-Gradua¸cão em Engenharia de Automa¸cão e Sistemas para a obten¸cão do Grau de Mestre em Engenharia de Automa¸cão e Sistemas.

Orientador: Prof. Dr. Leandro Buss Becker

Coorientador: Prof. Dr. Antˆonio Au-gusto Fr¨ohlich

Florian´opolis 2015

(4)

A ficha catalogr´afica ´e confeccionada pela Biblioteca Central.

Tamanho: 7cm x 12 cm

Fonte: Times New Roman 9,5

Maiores informa¸c˜oes em:

(5)

Esta Tese foi julgada aprovada para a obten¸cão do T´ıtulo de “Mestre em Engenharia de Automa¸cão e Sistemas”, e aprovada em sua forma final pela Programa de Pós-Gradua¸cão em Engenharia de Automa¸cão e Sistemas.

Florian´opolis, 01 de Julho 2015.

Prof. Dr. Jomi Fred Hubner Coordenador do Curso

Prof. Dr. Leandro Buss Becker Orientador

Prof. Dr. Antˆonio Augusto Fr¨ohlich Coorientador

Banca Examinadora:

Prof. Dr. Leandro Buss Becker Presidente

(6)

(7)

(8)

(9)

(10)

(11)

A realiza¸cão deste trabalho foi poss´ıvel gra¸cas ao apoio e parti-cipa¸cão de pessoas as quais possuo uma grande admira¸cão e respeito.

Além da realiza¸cão pessoal, pude crescer como pessoa, contando com a participa¸cão, técnica e particular, de grandes acadêmicos que me guiaram e me auxiliaram durante esta jornada, como também de pes-soas sempre queridas como minha fam´ılia e amigos, que me apoiaram e me encorajaram de inúmeras formas. Assim, gostaria de reportar meus sinceros agradecimentos:

Ao meu orientador Leandro Buss Becker, sem o qual este tra-balho não seria poss´ıvel. Agrade¸co sua disposi¸cão para discussões, dedica¸cão e orienta¸cão proporcionadas, que propiciaram boas contri-bui¸cões para elabora¸cão dessa obra. Um agradecimento especial pela paciência e amizade oferecida em todos os momentos.

Ao meu co-orientador Antˆonio Augusto Fr¨ohlich, que me ins-truiu nos primeiros passos dentro da academia e proporcionou diversos ensinamentos durante todo o processo.

Ao doutorando Fabio Basso, cuja participa¸cão e disposi¸cão em sempre ajudar foi fundamental. Agrade¸co sua aten¸cão, dedica¸cão, en-sinamentos e conselhos dados durante o desenvolvimento do trabalho.

A todos os amigos de laboratório, que também contribu´ıram com sua competência técnica e amizade para o desenvolvimento deste tra-balho. Um agradecimento especial ao Rodrigo Steiner, que ofereceu um grande apoio técnico em algumas partes do trabalho.

A meus pais Antônio Edson e Maria Salete, e irmã Mariana, que deram todo suporte necessário, com compreensão, confian¸ca e palavras de conforto e incentivo. Quero agradecer minha mãe, pela colabora¸cão na revisão desse trabalho.

A meus primos Vitor e Daniel, que contribu´ıram com sua ami-zade e apoio durante o desenvolvimento do trabalho.

A todos os meus amigos e demais familiares que sempre estive-ram presentes em minha vida, apoiando, divertindo e compartilhando novos momentos comigo.

(12)

(13)

possam apreci´a-lo e compreendˆe-lo. Isso ´

e - ou deveria ser - a mais elevada forma de arte.

(14)

(15)

Redes de Sensores Sem Fio (RSSF) vêm sido amplamente pesquisadas havendo uma grande evolu¸cão ao longo dos anos. As RSSFs estão rapi-damente se tornando uma ferramenta necessária em diferentes áreas de aplica¸cão, tais como monitoramento ambiental, saúde, seguran¸ca e ou-tras. A heterogeneidade de hardware é grande, por isso existe diversos ambientes que suportam programa¸cão de RSSF, podendo ser aplicados em diversos tipos de cenários. No entanto, a grande maioria de tais am-bientes visa apenas direcionar a programa¸cão de sensores, esquecendo-se de sua verdadeira inten¸cão: a aplica¸cão. Modelar uma RSSF para o uso eficaz é uma tarefa árdua, sendo necessários conhecimentos em linguagens de programa¸cão com baixo n´ıvel de abstra¸cão, dependente do sistema operacional, dos dom´ınios aos quais será implementada e das plataformas que se adequam melhor à aplica¸cão. Neste trabalho, propomos uma abordagem para satisfazer a necessidade de métodos de desenvolvimento de alto n´ıvel em aplica¸cões de RSSF, com o objetivo de fornecer uma liga¸cão clara entre as restri¸cões de RSSF modelados e as entidades de programa¸cão. Uma parte importante desta proposta é a cria¸cão do Perfil e do framework chamados WiSeN. O Perfil WiSeN ´

e perfil de UML dedicado para o projeto de aplica¸cões de RSSF, en-quanto o framework apresenta ferramentas que auxiliam a implanta¸cão de aplica¸cões para RSSFs desde a gera¸cão do código-fonte até o proces-samento dos dados coletados. No trabalho é discutido o uso do Perfil WiSeN em conjunto com o framework seguindo o paradigma de Desen-volvimento Dirigido por Modelos (DDM) que contribuem com um um conjunto significativo de recursos para gerar aplica¸cões de RSSFs em diferentes plataformas durante a implanta¸cão de novas aplica¸cões. Palavras-chave: 1. Perfil UML, 2. RSSF, 3. Desenvolvimento Diri-gido a Modelos

(16)

(17)

Wireless Sensor Networks (WSNs) have been widely researched and its evolution is increasing over the years. Wireless Sensor Networks (WSNs) are rapidly becoming a necessary tool in many different ap-plication areas, such as environmental monitoring, health, safety, and so on. The heterogeneity of hardware is large, so there exists seve-ral different environments that support WSN programming, they may be applied to various types of scenarios. However, the great majority of such environments only target the sensors programming, forgetting about their real intent: the application. Model a WSN for an effective use is an arduous task, it is necessary some knowledge in programming languages with a low level of abstraction, depending on the operating system, the domains in which will be implemented and the platforms that best suits the application. We propose an approach to satisfy the need of high level development methods in WSN applications, aiming to provide a clear link between the modeled WSN constraints and the programming entities. An important part of this proposal is the profile and framework so-called WiSeN. The WiSeN Profile is a UML profile devoted for WSN applications design, while the framework has tools to assist the deploy of applications for WSNs from the generation of source codes to the processing of the data collected. In this work is discussed the use of the WiSeN Profile together with the framework following the Model-Drivel Development (MDD) paradigm providing a significant set of resources to generate WSN applications on different platforms during the implementation of the new applications.

(18)

(19)

Figura 1 Componentes do hardware de um nodo sensor. . . 31 Figura 2 Diagrama de pacotes que possui o perfil MARTE.. . . 35 Figura 3 Domain-Specific Language apresentada em ( VICENTE-CHICOTE et al., 2007a). . . 47 Figura 4 DSL apresentada em (RODRIGUES et al., 2011). . . 48 Figura 5 Etapas para o DDM utilizando o método WiSeN. . . 72 Figura 6 Diagrama de pacotes que contém os pacotes importados dos perfil MARTE pelo perfil WiSeN. . . 74 Figura 7 Diagrama de Perfil que apresenta as tags propostas pelo perfil WiSeN e os pacotes em que estão contidas. . . 75 Figura 8 Diagrama de classes que modela uma aplica¸cão em RSSF. 79 Figura 9 Diagrama de Sequência que aplica o funcionamento de um nodo sensor. . . 80 Figura 10 Diagrama de Sequência que aplica o funcionamento de um nodo sink. . . 82 Figura 11 Diagrama de classes padrão para modelagem de uma aplica¸cão de RSSF. . . 84 Figura 12 Rela¸cões do MF Definidas por (CZARNECKI, 1998) . . . 86 Figura 13 Modelo com as features referentes à aplica¸cão e conexão selecionadas (as caixas preenchidas estão selecionadas). . . 88 Figura 14 Exemplifica¸cão de uma transforma¸cão utilizando o mo-delo de features em conjunto com o diagrama de classes . . . 91 Figura 15 N´ıveis organizacionais adotados para a implementa¸cão dos transformadores. . . 93 Figura 16 Ciclo do Desenvolvimento Dirigido à Testes. . . 94 Figura 17 Código fonte do test case criado para testar o transfor-mado do nodo sensor. . . 95 Figura 18 Diagrama com os componentes de inicializa¸cão do ga-teway. . . 97 Figura 19 Diagrama com a componentes usados para habilitar a sele¸cão de um arquivo de configura¸cão. . . 98 Figura 20 Diagrama com as tags de leitura para interpreta¸cão do arquivo de configura¸cão. . . 98 Figura 21 Diagrama que contém os componentes para a manipula¸cão

(20)

sink. . . 100

Figura 23 Diagrama que cont´em unicamente os componentes visu-ais.. . . 101

Figura 24 Interface dos componentes visuais visualizados no servi-dor de controle. . . 101

Figura 25 Diagrama que cont´em unicamente os componentes para cria¸c˜ao do arquivo de Log. . . 102

Figura 26 Log gerado pelo gateway. . . 102

Figura 27 Log convertido para XML. . . 103

Figura 28 C´odigo em linguagem Scala contendo o objeto Applica-tion e seus m´etodos para salvar e recuperar os dados do banco de dados . . . 104

Figura 29 Log convertido para Json. . . 105

Figura 30 Tela que cont´em a lista de dados contidos no BD. . . 106

Figura 31 Tela de apresenta¸cão do calculo da média dos valores escolhidos pelo usuário na lista da primeira tela. . . 107

Figura 32 Tela de demonstra¸cão do gráfico gerado pela sele¸cão dos valores escolhidos pelo usuário na lista da primeira tela.. . . 108

Figura 33 Estrutura especificada para o cen´ario de avalia¸c˜ao. . . 112

Figura 34 EPOSMoteI . . . 114

Figura 35 EPOSMoteII . . . 114

Figura 36 Divis˜ao da estrutura de acordo com a identifica¸c˜ao de cada nodo. . . 115

Figura 37 Modelo especificado para montar estrutura do pacote de mensagem. . . 116

Figura 38 Features selecionadas para representar o protocolo de acesso ao meio de acordo com a especifica¸c˜ao. . . 117

Figura 39 Features selecionadas para representar a transmiss˜ao de acordo com a especifica¸c˜ao. . . 117

Figura 40 Features selecionadas para especificar as caracter´ısticas dos nodos de acordo com a especifica¸c˜ao. . . 118

Figura 41 Features selecionadas para escolher o SO para a trans-forma¸c˜ao. . . 119

Figura 42 Features selecionadas para especificar as caracter´ısticas dos sensores de acordo com a especifica¸c˜ao. . . 119

(21)

Figura 44 Features selecionadas para representar as conex˜oes . . . 120

Figura 45 Features selecionadas para representar o a aplica¸c˜ao do nodo sink. . . 121

Figura 46 Features selecionadas para selecionar para qual tipo de nodo a aplica¸c˜ao deve ser gerada.. . . 122

Figura 47 Diagrama de classes que explora uma aplica¸cão de RSSF real para sensoriamento de temperatura usando um sensor digital . 123 Figura 48 Diagrama de classes que explora apenas os elementos que possuem varia¸cão quando usado um sensor analógico. . . 125

Figura 49 Diagrama que representa o inicio da transforma¸c˜ao. . . 126

Figura 50 Diagrama com a sequencia de transforma¸c˜ao do arquivo MakeDefs. . . 127

Figura 51 Entrada e Sa´ıda da transforma¸cão do arquivo MakeDefs.128 Figura 52 Arquivos gerados após a transforma¸cão. . . 128

Figura 53 Ambiente real controlado de acordo com a estrutura es-pecificada. . . 129

Figura 54 Modelo completo com todas as features propostas. . . 149

Figura 55 C´odigo gerado para a aplica¸c˜ao do nodo sensor. . . 179

Figura 56 C´odigo gerado para a aplica¸c˜ao do nodo sink. . . 180

Figura 57 Diagrama contendo todos os componentes do gateway implementado no LabView.. . . 181

(22)

(23)

AOP Aspect-Oriented Programming . . . 25 AOSD Aspect-Oriented System Design . . . 25 BD Banco de Dados . . . 25 CDFG Control and Data Flow Graph . . . 25 DBMS Database Management System . . . 25 DDM Desenvolvimento Dirigido a Modelos . . . 25 DSE Design Space Exploration . . . 25 DSML Domain Specific Modeling Language . . . 25 EPOS Embedded Parallel Operating System . . . 25 FBD Family-Based Design . . . 25 FOMDA Features-Oriented Model-Driven Architecture . . . 25 GUI Graphical User Interface . . . 25 HTTP Hypertext Transfer Protocol . . . 25 IAMM Internal Application Meta-Model . . . 25 IDE Integrated Development Environment . . . 25 IMM Implementation Meta-Model . . . 25 IP Internet Protocol . . . 25 IPMM Internal Platform Meta-Model . . . 25 M2M Model-To-Model . . . 25 M2T Model-To-Text . . . 25 MARTE Modeling and Analysis of Real-Time and Embedded

Sys-tems . . . 25 MDD Model-Driven Development . . . 25 MDE Model-Driven Engineering . . . 25 MF Modelo de Feature . . . 25 MMM Mapping Meta-Model . . . 25 ModES Model-driven Design of Embedded Systems . . . 25 MOF Meta Object Facility . . . 25 OCL Object Constraint Language . . . 25 ODBC Open Database Connectivity . . . 25 OMG Object Management Group . . . 25 OO Orientado a Objetos . . . 25

(24)

PDA Personal Digital Assistant . . . 25 PSM Platform Specific Model . . . 25 rCOs Relational Calculus of Object and Component Systems . 25 RDBMS Relational DataBase Management Systems . . . 25 RSM Repetitive Structure Modeling . . . 25 RTE Real Time Environment . . . 25 RTES Real Time and Embedded Systems . . . 25 RSSF Redes de Sensores Sem Fio . . . 25 SE Sistemas Embarcados . . . 25 SGBD Sistema Gerenciador de Banco de Dados . . . 25 SNA Sensor Network Appliance . . . 25 SO Sistema Operacional . . . 25 STR Sistemas de Tempo-Real . . . 25 TASK Tiny Application Sensor Kit . . . 25 TCP Transmission Control Protocol . . . 25 UML Unified Modeling Language . . . 25 VSL Value Specification Language . . . 25 WSAN Wireless Sensor and Actuator Network . . . 25 WSN Wireless Sensor Network . . . 25

(25)

1 INTRODUÇ ÃO . . . 25 1.1 MOTIVAÇ ÃO . . . 26 1.2 METODOLOGIA . . . 27 1.3 ESTRUTURA DO DOCUMENTO . . . 28 2 CONTEXTUALIZAÇ ÃO DO TRABALHO . . . 31 2.1 RSSF . . . 31 2.2 UML PROFILE . . . 33 2.3 DESENVOLVIMENTO DIRIGIDO POR MODELOS (DDM) 36 3 TRABALHOS RELACIONADOS . . . 41 3.1 GERAÇ ÃO DE C ÓDIGO A PARTIR DE MODELOS UML 41 3.2 PERFIL E MODELOS UML . . . 46 3.3 GERAÇ ÃO DE C ÓDIGO PARA RSSF . . . 47 3.4 MIDDLEWARE . . . 50 3.5 VISUALIZADORES DE DADOS . . . 51 3.6 DISCUSS ÃO . . . 54

4 FERRAMENTAS E TECNOLOGIAS UTILIZADAS . 61

4.1 WTC . . . 61 4.2 FERRAMENTAS DE MODELAGEM . . . 62 4.3 LABVIEW . . . 63 4.4 HEROKU . . . 64 4.5 MONGODB . . . 65 4.6 SISTEMAS OPERACIONAIS . . . 66 4.6.1 EPOS . . . 66 4.6.2 TinyOS . . . 67 5 M ´ETODO DE DESENVOLVIMENTO DIRIGIDO A

MODELOS PARA RSSF . . . 71 5.1 M ÉTODO WISEN . . . 71 5.2 PERFIL WISEN . . . 73 5.3 ABORDAGEM DDM PARA RSSF . . . 79 5.3.1 Diagrama de Classes . . . 83 5.3.2 O Modelo de Feature WiSeN . . . 86 6 O FRAMEWORK WISEN . . . 89 6.1 TRANSFORMADORES . . . 89 6.1.1 Desenvolvimento dos transformadores . . . 93 6.2 LEITOR DE DADOS (GATEWAY ) . . . 96 6.3 WEBSERVICE DE INTEGRAÇ ÃO . . . 104 6.4 APLICATIVO MOBILE . . . 106

(26)

7.2 ESTRUTURA . . . 111 7.2.1 Sensores . . . 113 7.2.2 Motes . . . 114 7.3 ESPECIFICAÇ ÃO . . . 115 7.3.1 Modelos de Features . . . 116 7.3.2 Diagrama de Classes . . . 122 7.4 TRANSFORMAÇ ÃO . . . 126 7.5 IMPLANTAÇ ÃO . . . 128 7.6 INTEGRAÇ ÃO . . . 129 7.7 AVALIAÇ ÃO . . . 130 8 CONCLUS ÃO . . . 133 REFER ÊNCIAS . . . 137 AP ÊNDICE A -- Guia de uso das Features . . . 149 AP ÊNDICE B -- Guia de uso das Tags . . . 167 AP ÊNDICE C -- Dependências . . . 175 AP ÊNDICE D -- Códigos e Diagramas de Blocos . . . 179

(27)

1 INTRODUC¸ ˜AO

O Desenvolvimento Dirigido a Modelos (DDM), ou em inglês Model-Driven Development (MDD), tem como idéia básica gerar um código-fonte para uma plataforma de software espec´ıfica a partir de um modelo de linguagem denominado DSL (Domain Specific Language). O MDD surgiu devido à necessidade de se desenvolver softwares indepen-dentemente de plataformas e com um alto ´ındice de reuso (MELLOR; CLARK; FUTAGAMI, 2003)

Devido ao alto n´ıvel de abstra¸cão que o DDM fornece, é poss´ıvel capturar o comportamento e restri¸cões da aplica¸cão, auxiliando na iden-tifica¸cão de pontos que precisem ser otimizados durante a implanta¸cão. Isto faz com o DDM se torne adequado para o desenvolvimento de sis-temas embarcados, como as Redes de Sensores Sem Fio (RSSF) ou, em inglês, Wireless Sensor Networks (WSNs) (AKYILDIZ et al., 2002; CHONG; KUMAR, 2003; CULLER; ESTRIN; SRIVASTAVA, 2004), pois es-tas redes podem ser entendidas como sistemas compostos de pequenos dispositivos embarcados.

Comumente, as RSSFs são usadas para monitoramento de am-bientes inóspitos e de dif´ıcil acesso através de sensoriamento cont´ınuo e controle local de atuadores. Do ponto de vista da aplica¸cão, o que realmente importa são os dados coletados a partir das RSSFs, os quais devem ser transmitidos dos sensores para algum tipo de servidor, de forma a serem posteriormente armazenados e processados. Porém, a configura¸cão destas redes não é algo trivial.

Durante os projetos, ´e comum que os projetistas de aplica¸c˜oes de RSSFs gastem muito tempo com detalhes de baixo n´ıvel relacionados `

a programa¸cão dos sensores. Percebe-se que, normalmente, isto ocorre porque o fluxo de um projeto em RSSF é iniciado codificando-se as aplica¸cões diretamente na linguagem de programa¸cão.

De fato, as funcionalidades adicionais deveriam ser programadas ou pelo menos configuradas, nos nodos sensores como, por exemplo, a frequência para coleta de dados e transmissão, o padrão de trans-missão de mensagens (e.g. broadcast ou ponto-a-ponto), a pol´ıtica de roteamento das mensagens, entre outros. Dessa forma, assumindo que tais funcionalidades são fornecidas por um Sistema Operacional (SO) embarcado, seria desejável que tais aplica¸cões pudessem ser modeladas e testadas num n´ıvel de abstra¸cão mais elevado quando houvesse al-tera¸cões nos objetivos de cada aplica¸cão, o que permitiria ao projetista somente se preocupar em configurar adequadamente o SO.

(28)

O uso de linguagens de modelagem como UML (OMG, 2012) para o desenvolvimento de aplica¸cões em RSSF é uma abordagem muito promissora (SADILEK, 2008). São linguagens de fácil compreensão e permitem que os projetistas modelem um sistema sem a necessidade de conhecimentos em linguagem de programa¸cão, podendo focar seus esfor¸cos apenas na aplica¸cão. Além disso, elas são altamente acopláveis a outras tecnologias, aumentando o seu n´ıvel de abstra¸cão.

Visando uma simplifica¸cão ao longo do desenvolvimento de aplica¸cões para RSSFs, este trabalho apresenta um método orientado a modelos, chamado de método WiSeN, que aumenta o n´ıvel de abstra¸cão do desenvolvimento , permitindo que os projetistas se concentrem na aplica¸cão, sem a necessidade de lidar com os detalhes de baixo n´ıvel.

Junto ao método, a abordagem proposta inclui o perfil e o fra-mework WiSeN que, criados para facilitar a especifica¸cão e implanta¸cão de aplica¸cões de RSSF, possuem como finalidade sua utiliza¸cão sob a perspectiva do DDM.

Como meio verificar se a proposta atinge os objetivos, neste trabalho será apresentado um cenário de avalia¸cão que visa aplicar o método WiSeN para implantar uma Rede de Sensores sem Fio utili-zando as ferramentas propostas.

1.1 MOTIVAC¸ ˜AO

O Desenvolvimento Dirigido a Modelos vem se tornando um pa-radigma importante para a produ¸cão de sistemas por meio de espe-cifica¸cões de alto n´ıvel utilizando requisitos de hardware e software (SELIC, 2007; SADILEK, 2007). Entretanto, dentro deste tema há uma carência de propostas que tratam detalhadamente e exclusivamente de sistemas para RSSF, razão pela qual, com algumas exce¸cões na litera-tura como as que estão descritas na se¸cão 3,

“os desenvolvedores geralmente tˆem de lidar com problemas de sistema em baixo n´ıvel, as-sim como com o design de protocolos dis-tribu´ıdos”.(MOTTOLA; PICCO, 2011)

Corpora¸cões que realizam a análise de tecnologias contem-porâneas, como (ONWORLD, 2013) e (CONET, 2013) afirmam que

“apesar dos avan¸cos de hardware representarem um papel significativo no tema RSSF, o poder desta tecnologia apenas poder´a ser plenamente aproveitado se plataformas de software

(29)

adequa-das estiverem dispon´ıveis para os desenvolvedo-res de aplicativos”.

Neste sentido, o uso de modelos permite não só uma melhor compreensão do problema, como torna poss´ıvel o aumento do n´ıvel de abstra¸cão no desenvolvimento de aplica¸cões para RSSF.

Alguns desses conceitos estão sendo usados em ( VICENTE-CHICOTE et al., 2007b; RODRIGUES et al., 2011) onde diferentes n´ıveis de abstra¸cões foram definidos para construir aplica¸cões de RSSF.

Portanto, através de modelos que atendam a arquitetura de uma RSSF é poss´ıvel gerar uma gama de aplica¸cões e facilitar a gera¸cão e implementa¸cão de novas aplica¸cões para interpreta¸cão dos dados, razão pela qual é poss´ıvel ter uma considerável evolu¸cão no que diz respeito ao monitoramento de ambientes. Porém, segundo (HAC, 2003):

“a implanta¸cão de grandes redes de sensores exige ferramentas para coletar e consultar seus dados. Há interesses particulares agregados a opera¸cões que se resumem a valores mo-mentâneos de parte dos sensores ou para toda uma rede de sensores. Dada uma densa rede de milhares de sensores que consultam por exemplo, a temperatura, os usuários querem saber padrões de temperatura em regiões relativamente gran-des, abrangendo dezenas de sensores, e as leitu-ras dos sensores individuais são de pouco valor.”

Considerando as afirma¸cões acima, a motiva¸cão deste traba-lho visa facilitar aos desenvolvedores, que não detenham conhecimento técnico aprofundado sobre sistemas embarcados, possam realizar a im-planta¸cão de aplica¸cões de RSSF com um framework que os auxilie desde a coleta até a visualiza¸cão final dos dados.

1.2 METODOLOGIA

O objetivo deste trabalho é realizar um Desenvolvimento Diri-gido a Modelos de forma que seja poss´ıvel, a partir de modelos prede-finidos e configuráveis, gerar aplica¸cões para redes de sensores sem fio desde a codifica¸cão em multiplataformas até a interface com os usuários finais, visando um desenvolvimento amigável com uma alta usabilidade. Para demonstrar a proposta em questão, foi utilizada uma me-todologia de pesquisa baseada na apresenta¸cão de um cenário de ava-lia¸cão. Utilizando enfoques exploratórios e descritivos, buscou-se

(30)

iden-tificar a multiplicidade de dimens˜oes presentes numa situa¸c˜ao previ-amente estabelecida para o atingimento dos objetivos deste trabalho. Para isso, as seguintes tarefas foram executadas:

• Investigar como o uso de uma abordagem dirigida a modelos pode auxiliar no desenvolvimento de aplica¸c˜oes para RSSF, aumen-tando o n´ıvel de abstra¸c˜ao e reuso.

• Criar um perfil UML que atenda as necessidades da modelagem de alto n´ıvel para RSSF.

• Desenvolver transformadores de modelos para permitir a mi-gra¸c˜ao dos modelos em alto n´ıvel para as plataformas EPOS-MOTEII e EPOSMoteI/Meshnetics.

• Implementar um gateway para o recebimento dos dados e um sistema de monitoramento para o servidor de controle, de forma que ambas as aplica¸c˜oes possam ser configuradas e integradas a partir de modelos de alto n´ıvel.

• Implementar um aplicativo de visualiza¸cão dinâmica para o mo-nitoramento remoto a partir de dispositivos móveis (celulares ou tablets).

• Demonstrar o método proposto através de um cenário de ava-lia¸cão aplicando todo ciclo de desenvolvimento proposto.

• Coletar dados quantitativos relacionados as perspectivas usadas no trabalho para avaliar sua eficiência, como: Tamanho dos mo-delos, quantidade de códigos gerados, utiliza¸cão dos geradores e quantidade de features selecionadas.

No estudo foram utilizados dois SOs diferentes, denominados EPOS e TinyOS, em conjunto com duas plataformas livres para RSSF, denominadas EPOSMoteII e EPOSMoteI/Meshnetics que serviram de material privilegiado de análise, exemplifica¸cão e utiliza¸cão do fra-mework em múltiplas plataformas.

1.3 ESTRUTURA DO DOCUMENTO

O restante do trabalho est´a organizado como segue:

O Cap´ıtulo 2 faz uma revis˜ao conceitual sobre as tecnologias utilizadas no trabalho.

(31)

O Cap´ıtulo 3 descreve trabalhos relacionados com o tema de estudo em quest˜ao.

O Cap´ıtulo 4 faz uma introdu¸c˜ao das ferramentas que foram utilizadas no presente trabalho.

O Cap´ıtulo 5 analisa a proposta do método WiSeN para o De-senvolvimento Dirigido a Modelos para RSSF junto com os modelos, perfis e framework WiSeN propostos para a gera¸cão das aplica¸cões.

O Cap´ıtulo 6 faz uma apresenta¸c˜ao sobre o framework WiSeN proposto e aborda como as ferramentas interagem entre si.

O Cap´ıtulo 7 apresenta um cenário de avalia¸cão para o Desen-volvimento Dirigido a Modelos. Esse estudo apresenta um exemplo que ilustra a aplica¸cão do método WiSen durante a especifica¸cão de um modelo de alto n´ıvel para uma aplica¸cão t´ıpica de RSSF que con-sidera o dom´ınio de WSN requerido e faz uso da proposta de Perfil WISeN junto ao framework. Esse exemplo também abrange a gera¸cão de código-fonte.

(32)

(33)

2 CONTEXTUALIZAC¸ ˜AO DO TRABALHO

Este capitulo apresenta alguns conceitos fundamentais para com-preens˜ao das tecnologias utilizadas neste trabalho.

2.1 RSSF

Uma Rede de Sensores Sem Fio (RSSF) ´e um tipo particular de redes ad-hoc com uma s´erie de caracter´ısticas e requisitos espec´ıficos.

Seus nodos são formados por “sensores inteligentes”, isto é, pe-quenos dispositivos equipados com avan¸cadas funcionalidades de senso-riamento (térmico, pressão, acústico, etc.), um processador, uma fonte de energia (interna ou externa) e transceivers para transmissão a curtas distâncias (SANTI, 2005;CARLE; SIMPLOT-RYL, 2004), representado na Figura 1. Devido a sua limita¸cão de processamento, armazenamento e, na maioria das vezes, consumo de energia, os dispositivos se limitam a coletar, eventualmente agregar, e transmitir seus próprios dados e os dos seus vizinhos para os nodos sorvedouros.

Figura 1 – Componentes do hardware de um nodo sensor.

´

E constitu´ıda uma rede de sensores sem fio, quando dois ou mais dispositivos colaboram entre si usando comunica¸cão sem fio e um fluxo de dados assimétrico de muitos para um (CARLE; SIMPLOT-RYL, 2004). Seu principal objetivo é realizar tarefas de sensoriamento de forma dis-tribu´ıda em benef´ıcio de aplica¸cões clientes. Nesse tipo de rede, nodos trocam informa¸cões sobre um ambiente a fim de construir uma visão

(34)

global da região monitorada, que se torna acess´ıvel ao usuário externo através de um ou mais nodos gateways, os quais são muitas vezes partes intr´ınsecas das redes de sensores e são obrigados a conectar os dados entre as redes de sensores e dispositivos de outras redes. Portanto, essas redes funcionam como poderosos sistemas de aquisi¸cão de dados ambientais. Os dados são coletados através dos sensores distribu´ıdos e entregues a pontos de sa´ıdas da rede, chamados nodos sorvedouros, a fim de sofrerem análise e processamento adicional.

Para que seja efetuada uma modelagem adequada em alto n´ıvel de abstra¸cão, é necessário definir as principais caracter´ısticas que en-volvem uma RSSF. Esta tarefa é relativamente complexa sendo este um assunto que possui uma constante evolu¸cão e a todo momento apare-cem e somem novas propriedades a seu respeito. Além das constantes mudan¸cas, muitos de seus componentes exigem estudos extremamente detalhados para que seja poss´ıvel atingir um n´ıvel alto de maturidade. Por exemplo, algumas caracter´ısticas como a fonte de energia que são utilizada pelos nodos, possuem diversas variáveis e protocolos para des-crever sua funcionalidade. O mesmo é válido para protocolos de comu-nica¸cão, que estão em constante aprimoramento e há sempre novos tipos sendo propostos. Estas propriedades poderiam gerar novos estudos que contemplariam somente suas peculiaridades.

Na literatura, são encontradas excelentes pesquisas que abor-dam os conceitos funabor-damentais de RSSFs de uma maneira simplifi-cada, como mostrado em (MOTTOLA; PICCO, 2011; ZHAO; GUIBAS, 2004;YICK; MUKHERJEE; GHOSAL, 2008;BARONTI et al., 2007; AKYIL-DIZ et al., 2002). Estas pesquisas descrevem as necessidades e solu¸cões relacionadas a concep¸cão, programa¸cão e configura¸cão de hardware e software.

Os principais aspectos introduzidos por estas obras foram exa-minadas e como resultado, observou-se todos os atributos, associa¸cões e restri¸cões necessárias para especificar uma aplica¸cão de RSSF. Em resumo, os seguintes aspectos foram identificados:

Aplica¸cão − Para descrever uma aplica¸cão, são desejáveis a re-presenta¸cão de vários elementos. Alguns destes elementos como a taxo-nomia, os padrões de intera¸cão e a mobilidade são cruciais para idealizar o cenário.

Atuador − Após ser definida a aplica¸cão, algumas medidas po-dem ser tomadas a partir das informa¸cões recebidas. Para isto, equipa-mentos de automa¸cão, monitoramento de ambientes e/ou outros con-troles podem ser utilizados em uma aplica¸cão.

(35)

rede devem ser especificadas. Isso pode depender desde o número máximo de nodos emissores e receptores até a topologia que será utili-zada, ou até mesmo o comportamento esperado pela rede.

Nodo − Algumas informa¸cões não funcionais são necessárias para que a modelagem da aplica¸cão torne-se poss´ıvel. Entre elas é poss´ıvel citar os diferentes atributos que podem ser usados dentro da plata-forma escolhida, quais sensores dispon´ıveis (por exemplo, temperatura, pressão), quais as fontes de alimenta¸cão (por exemplo, solar, bateria), sistemas operacionais, drive do rádio, entre outros. Fora isso, ainda existem as caracter´ısticas que não são f´ısicas, tais como, a posi¸cão es-pacial, os vizinhos de cada nodo, per´ıodo de hiberna¸cão do node, entre outros.

Comunica¸cão − É uma das partes mais cruciais do trabalho. Aborda como os nodos se comunicam entre si dentro da rede. Diferentes tipos de protocolos de roteamento estão dispon´ıveis. Para que a escolha seja bem feita, devem ser considerados, por exemplo, quais tipos de mensagens serão transmitidas, a eficiência energética e a sincroniza¸cão das mensagens entre as transmissões.

Nos estudos realizados, notou-se que embora o ambiente de aplica¸cão das RSSF possa variar consideravelmente, seu funcionamento básico permanece praticamente o mesmo. Com os conceitos arquitetu-rais citados abaixo é poss´ıvel modelar uma aplica¸cão para RSSF, sendo eles:

1. Os nodos sensores devem coletar informa¸c˜oes de suas unidades de sensoriamento;

2. os nodos sensores enviam os dados coletados para o nodo sink ; 3. o nodo sink recebe os dados e os armazena em um servidor atrav´es

de um gateway; e

4. o gateway processa os dados usando programas de an´alise.

2.2 UML PROFILE

Analisando as defini¸cões apresentadas pela OMG (OMG, 2011) definiu-se um perfil da UML (RUMBAUGH; JACOBSON; BOOCH, 2004) como sendo extensões limitadas a um metamodelo de referência com o objetivo de adaptar o metamodelo a uma plataforma ou dom´ınio es-pec´ıfico. Portanto, um perfil é uma espécie de pacote que estende um metamodelo de referência. A estrutura principal é o estereótipo, que é

(36)

definida como parte dos perfis. Um perfil apresenta várias limita¸cões ou restri¸cões em metamodelos comuns através da utiliza¸cão das meta-classes definidas neste pacote.

Um estereótipo define como uma meta-classe existente pode ser estendida, e permite o uso de plataformas ou terminologias espec´ıficas de dom´ınio no lugar, ou além, dos usados para nestas meta-classes. As-sim como uma classe, um estereótipo pode ter propriedades que podem ser referenciadas como tag. Quando um estereótipo é aplicado a um elemento do modelo, os valores das propriedades podem ser referidos como sendo os valores das tags.

Portanto, um perfil é uma biblioteca (disponibilizada na forma de pacotes) que possui defini¸cões para complementar metamodelos que podem ser referenciados. Este pacote possui diversos estereótipos que possibilitam que o perfil seja aplicado a meta-classes existentes. Os estereótipos, por sua vez, possuem tags que atuam como caracter´ısticas funcionais e não funcionais, recebendo e disponibilizando valores com o objetivo de adaptar o meta-modelo a uma plataforma ou dom´ınio espec´ıfico.

O perfil MARTE (Modeling and Analysis of Real-Time and Em-bedded Systems, ou em português Modelagem e Análise de Tempo-Real e Sistemas Embarcados) (OMG, 2009) foi proposto para substituir o perfil UML SPT (OMG, 2005). O MARTE é hoje um dos principais padrões de modelagem para projetos de sistemas embarcados e esta fi-cando cada vez mais popular. Este padrão visa aprimorar a UML para lidar com as necessidades espec´ıficas de Sistemas de Tempo Real (STR) e Sistemas Embarcados (SE).

Este perfil define conceitos para descri¸cões baseadas em modelos, análise em tempo real e sistemas embarcados. A inten¸cão não é definir novas técnicas para a análise de sistemas de tempo real e sistemas em-barcados, mas sim apoiá-las. A ideia inicial era permitir a constru¸cão de modelos UML preditivos que poderiam ser utilizados para anali-sar as propriedades principais do sistema - tais como o desempenho, escalonabilidade e pré-requisitos para seu funcionamento - antes que o sistema fosse constru´ıdo. Isso significa oferecer aos projetistas uma maneira fácil de projetar hardware e software, contendo os aspectos da RTES com a capacidade de anexar informa¸cões quantitativas a um modelo UML. Além disso, os padrões utilizados por MARTE permitem uma interoperabilidade entre ferramentas de modelagem, ferramentas de análise de modelos, ferramentas para a gera¸cão de código, entre outros.

(37)

diferen-Figura 2 – Diagrama de pacotes que possui o perfil MARTE.

tes tipos de atributos que podem ser agregados ao sistema modelado. Esta estrutura foi criada visando duas questões principais de modela-gem: As caracter´ısticas de um STR e SE e a descri¸cão da aplica¸cão, de modo a apoiar a análise das propriedades do sistema. Desta forma, o perfil MARTE foi dividido em quatro pacotes distintos, como mostrado na Figura 2.

• Funda¸cões MARTE − Contém defini¸cões comuns para descrever o tempo e uso de recursos concorrentes. A maioria deles são com-partilhados com as duas partes principais, o “Modelo de Design MARTE”e o “Modelo de Análise MARTE”.

(38)

• Modelo de Design MARTE − Fornece conceitos de alto n´ıvel para a modelagem de caracter´ısticas quantitativas e qualitativas de sis-temas ou protocolos de tempo real. Além disso, também descreve alguns recursos de hardware e software que podem ser utilizados na execu¸cão de uma aplica¸cão.

• Modelo de Análise MARTE − Trabalha principalmente com ava-lia¸cões precisas utilizando análises quantitativas formais e tempo; além disso, define também um quadro de análise geral, que tem a inten¸cão de refinar algum outro tipo de análise, tais como con-sumo de energia, uso de memória, ou a confiabilidade.

• Anexos MARTE − Cont´em os perfis anexos definidos no MARTE tais como VSL MARTE (Value Specification Language), RSM (Repetitive Structure Modeling) e bibliotecas pr´e-definidas que podem ser usadas pelos modeladores.

No entanto, os recursos oferecidos pelo MARTE se concentram principalmente em atender as peculiaridades de sistemas embarcados. Ao lidar com RSSF, esta tecnologia possui suas próprias peculiarida-des, o MARTE possui algumas desvantagens e observou-se que alguns melhoramentos são necessários para torná-lo mais adequado para a mo-delagem de aplica¸cões. No que diz respeito a RSSF, por exemplo, ca-racter´ısticas adicionais devem ser inclu´ıdas ao perfil, tais como comu-nica¸cão, sensoriamento e sincroniza¸cão, gerando a necessidade de com-plementa¸cão para que atenda as exigências da modelagem de aplica¸cões para RSSF. Além disso, alguns conceitos como estrutura de mensagens e as peculiaridades do nodo, não existem no MARTE conforme será visto no capitulo 5.

2.3 DESENVOLVIMENTO DIRIGIDO POR MODELOS (DDM)

Desenvolvimento Dirigido por Modelos (SELIC, 2003) é uma espe-cializa¸cão contida na Engenharia Dirigida por Modelos (EDM) ou, em inglês, Model-Driven Engineering(MDE) descrita em (SCHMIDT, 2006) como uma abordagem promissora para lidar com a complexidade de di-ferentes plataformas e expressar conceitos de dom´ınio de forma eficaz. A EDM combina tecnologias como Domain-specific modeling languages (DSML) e Transformation engines and generators.

De acordo com (BéZIVIN, 2005), para se compreender o termo “modelo”, deve-se levar em considera¸cão o contexto em que o mesmo é utilizado. Para sistemas relacionados à computa¸cão, há uma defini¸cão

(39)

consensual de modelo dada por Rothenberg (ROTHENBERG, 1989), que diz:

“modelagem, no sentido mais amplo, é o uso econômico de algo no lugar de outra coisa para algum propósito cognitivo. Ela permite usar algo que é mais simples, mais seguro ou mais barato do que a realidade para algum propósito. Um modelo representa a realidade para um determi-nado propósito; o modelo é uma abstra¸cão da re-alidade, no sentido de que ele não pode represen-tar todos os aspectos da realidade. Desta forma, ´

e poss´ıvel lidar com o mundo de uma forma sim-plificada, evitando a complexidade, o perigo e a irreversibilidade da realidade”.

O uso de modelos se torna cada vez mais significante tanto para o desenvolvimento e engenharia de softwares quanto em qualquer outra disciplina da engenharia. Para usar estes potenciais benef´ıcios que a EDM prega, o DDM surgiu com o objetivo de amadurecer estas t´ecnicas ao ponto que elas possam ser aplic´aveis.

Segundo (SELIC, 2003), uma das principais vantagens do DDM ´

e a possibilidade de expressar modelos usando conceitos que são muito menos ligados à tecnologia a ser implementada e mais à proximidade junto ao dom´ınio do problema, considerado um problema para as lin-guagens de programa¸cão mais populares. Estas vantagens fazem com que os modelos sejam mais fáceis de especificar, de serem compreen-didos e atualizados. Com isso, a modelagem dos sistemas pode ser atribu´ıda a especialistas de dom´ınio ao invés de especialistas em tecno-logia, melhorando a qualidade do software e aprimorando a utiliza¸cão dos recursos. Os modelos gerados acabam sendo menos sens´ıveis a plataformas que serão utilizadas e mais independente em rela¸cão as mudan¸cas evolutivas da tecnologia.

Com o avan¸co das técnicas e ferramentas foi poss´ıvel alcan¸car um grau de maturidade que tornou viável o uso de DDM mesmo em aplica¸cões industriais de larga escala. A utiliza¸cão do DDM em pro-jetos industriais em diversas áreas se torna cada vez mais comum, e mais casos de sucesso são divulgados a cada dia (HUTCHINSON; ROUN-CEFIELD; WHITTLE, 2011). Uma pesquisa realizada pela Middleware Company (COMPANY, 2003) indicou que com o uso de DDM no projeto houve um acréscimo de 37% na produtividade.

De acordo com (HERRINGTON, 2003), a gera¸cão de código não se limita a ser apenas uma maneira rápida de produzir código fonte. Outros benef´ıcios podem ser alcan¸cados durante o processo conforme

(40)

segue:

• Qualidade: ferramentas geradoras de código utilizam templates para produzir um código (para uma plataforma alvo) a partir de elementos especificados em modelos de alto n´ıvel. Quanto maior e mais completo for o conjunto de templates, melhor é a qualidade do código fonte obtido. Se os templates descreverem uma gera¸cão de código otimizada com base em critérios de otimiza¸cão e qua-lidade de design, o aumento de quaqua-lidade é refletido no código fonte final;

• Consistência: a padroniza¸cão de nomenclatura para classes, métodos e atributos é totalmente consistente no código gerado. Tal padroniza¸cão facilita a interface entre classes e suas utiliza¸cões porque os padrões utilizados foram definidos dentro dos templa-tes;

• Produtividade: a gera¸cão de código aumenta os ganhos de produ-tividade, devido à sua capacidade de adaptar-se rapidamente às mudan¸cas durante o projeto. Em outras palavras, as modifica¸cões na especifica¸cão podem ser propagadas automaticamente para a implementa¸cão do sistema. Além disso, como a gera¸cão de código pode comprimir o tempo em determinados projetos, resta mais tempo para ser gasto com uma modelagem adequada e testes do protótipo, evitando retrabalhos no futuro.

• Abstra¸cão: vantagens em termos de n´ıvel de abstra¸cão de projeto podem ser obtidas usando ferramentas de gera¸cão de código que funcionam com parâmetros de entrada (por exemplo, modelos es-truturais e de comportamento do sistema, os modelos da base de dados ou defini¸cões sobre as interfaces de usuário,etc.) em um formato que seja independente de linguagem. Em outras pala-vras, é poss´ıvel gerar o código-fonte para diferentes linguagens de programa¸cão (tais como Java, Smalltalk ou C++) a partir de um mesmo modelo abstrato.

Porém, a gera¸cão de código é um recurso somente poderoso quando usado apropriadamente e pode ser muito trabalhoso quando usado em circunstâncias erradas. Para obter uma solu¸cão eficaz é ne-cessário usar uma série de ferramentas heterogêneas que devem estar bem adaptadas para suas tarefas espec´ıficas.

A estabilidade do projeto e o conjunto de recursos devem ser considerados. Quando o conjunto de recursos n˜ao ´e particularmente

(41)

estável, ou o projeto para a implementa¸cão é periodicamente alterado junto com as tecnologias, é preciso avaliar se a gera¸cão de códigos é a melhor op¸cão, já que seu uso torna-se realmente útil apenas após um grande esfor¸co de planejamento e implementa¸cão dos componentes de transforma¸cão de códigos.

O princ´ıpio do DDM é especificar a funcionalidade do sistema utilizando um modelo independente de plataforma (PIM) usando um DSL apropriado. O PIM fornece uma especifica¸cão do sistema que seja adequado para a sua implementa¸cão em diferentes plataformas. Além disso, este PIM é traduzido para um modelo especifico de plata-forma (PSM), que, por sua vez, oferece um ponto de vista espec´ıfico da plataforma do sistema, por exemplo, ele combina o PIM com as espe-cifica¸cões que o sistema irá utilizar para uma determinada plataforma. A fim de possibilitar esta transforma¸cão (ou mapeamento), um modelo de plataforma (PM) deve ser fornecido. O PSM fornece um conjunto de conceitos técnicos, representando as diferentes partes e os diferentes servi¸cos que compõem a plataforma. Ele também proporciona conceitos que representam os diferentes tipos de elementos para serem utilizados na especifica¸cão e qual plataforma deve ser utilizado pela aplica¸cão. Ao final deste processo é realizada a gera¸cão de códigos para auxiliar na constru¸cão de novas aplica¸cões.

Gera¸cão de código significa usar um ou mais programas de com-putador para auxiliar na produ¸cão de código-fonte, seja o código-fonte de aplicativos, códigos para a configura¸cão da plataforma, entre outros. Resumidamente, pode-se dizer que um programa gerador de código é um conjunto de transformadores que recebem como entrada especi-fica¸cões de alto n´ıvel, normalmente em formato de modelos, a fim de criar um ou mais arquivos de código-fonte como sa´ıda. Esses transfor-madores formam um conjunto de templates que adequam os arquivos de sa´ıda de acordo com as informa¸cões proporcionadas a partir dos modelos de entrada.

Os transformadores especificados em ferramentas como ( BOO-COCK, 2013) e (OLDEVIK, 2005) são estáticos. Um transformador é estático quando não é poss´ıvel modificar a sua transforma¸cão. Existem propostas em que os transformadores são dinâmicos (WILLINK, 2003). Em transformadores dinâmicos é poss´ıvel modificar as transforma¸cões que ele realiza, assim como criar novos transformadores a partir de transformadores pré-fabricados. Como as tecnologias dispon´ıveis para desenvolver um sistema mudam com frequência (GRAAF; LORMANS; TOETENEL, 2003; BASSO; BECKER; OLIVEIRA, 2006), a maioria dos transformadores de modelos precisam ser reescritos para efetuar novas

(42)

transforma¸cões. Isto ocorre porque eles são desenvolvidos para aplicar transforma¸cões voltadas à uma tecnologia espec´ıfica. Logo, eles não são reutilizáveis se existirem mudan¸cas nas tecnologias utilizadas pelos sistemas.

Apenas após o desenvolvimento de toda a estrutura de trans-formadores, é poss´ıvel gerar um volume significativo de códigos que poderão ser empregues ao trabalho. Esta disserta¸cão aplica na prática alguns conceitos de transforma¸cões dinâmicas baseadas em Linhas de Produto de Software, ou Software Product Lines (SPL)(BASSO et al., 2013).

(43)

3 TRABALHOS RELACIONADOS

Neste cap´ıtulo serão apresentados os trabalhos relacionados com este tema de mestrado. Por se tratar de um estudo que envolve a in-tegra¸cão de diferentes tecnologias coletamos diferentes referências em diversos campos de pesquisa e, por isso, os trabalhos foram classifica-dos por assuntos. Apesar classifica-dos trabalhos estarem alocaclassifica-dos à se¸cão que indica o tema principal do estudo, muitas das referencias deste cap´ıtulo também tratam da integra¸cão de mais de uma tecnologia conforme dis-cutido a seguir.

3.1 GERAÇ ÃO DE C ÓDIGO A PARTIR DE MODELOS UML

Na literatura, há muitas abordagens diferentes para gerar código fonte a partir de modelos UML. Alguns destes trabalhos usam so-mente um diagrama (por exemplo, diagrama de classes), enquanto ou-tros usam uma combina¸cão de diferentes diagramas (por exemplo, di-agramas de classe com diagrama de estado, sequência e/ou atividade) para gerar códigos que vão desde a constru¸cão das classes até códigos que contém o comportamento dos elementos do sistema. Esta se¸cão apresenta algumas propostas para gerar código a partir de modelos UML, bem como ferramentas comerciais que implementam tal gera¸cão de código.

Um trabalho importante para este estudo está apresentado em (BASSO; BECKER; OLIVEIRA, 2006) onde a abordagem FOMDA para desenvolvimento de sistemas de tempo real embarcados é explorada.O principal objetivo da abordagem FOMDA é definir uma solu¸cão para projetistas identificarem mapeamentos e transforma¸cões de modelos de sistemas. Nesta abordagem, o Modelo de Features é utilizado para identificar plataformas. Estas são usadas para identificar modelos fonte (especificados em alto n´ıvel) e modelos alvo (dependentes de uma pla-taforma). Esta identifica¸cão representa um mapeamento. Este deter-mina uma transforma¸cão que deve ser realizada por uma caracter´ıstica do FM para, a partir do modelo fonte, gerar o modelo alvo.

Neste trabalho, foi utilizada a FOMDA Toolkit, também dis-cutida em (BASSO; BECKER; OLIVEIRA, 2006), que é uma ferramenta protótipo que dá suporte à abordagem FOMDA. Ela é utilizada por um projetista de uma aplica¸cão para transformar um modelo especificado em alto n´ıvel em um código para uma aplica¸cão.

(44)

Como complemento, os autores em (BASSO; OLIVEIRA; FARIAS, 2014) apresentam uma API Java que estende o framework de testes JUnit, usada comumente para automatizar casos de teste para as fun-cionalidades de aplica¸cões, e atualmente aplicado para testar trans-forma¸cões variantes com desempenho semelhante ao da API padrão, também utilizados nesse estudo. A forma como estes trabalhos foram utilizados neste estudo será aprofundada na se¸cão 6.1.1.

O trabalho apresentado por (HARRISON; BARTON; RAGHAVA-CHARI, 2000) demonstra o mapeamento de diagramas de classes para o código-fonte Java. Esta abordagem visa a gera¸cão de classes skeletons de alto n´ıvel, o que permite a abstra¸cão dos detalhes sobre os atributos da implementa¸cão a partir do ponto de vista da classe implementada, como por exemplo, os tipos de dados dos atributos. Em outras palavras, a implementa¸cão não precisa “enxergar” os atributos porque os valores que foram atribu´ıdos a eles são acessados através de métodos get/set. O processo de gera¸cão de código só considera as classes do modelo UML decoradas com o estereótipo << Entidade >>. Cada entidade é mapeada para uma interface e um par de classes que implementam esta interface, ou seja, para cada entidade X, os seguintes elementos Java são gerados: (i) uma interface, (ii) uma classe abstrata chamada XAbst, e (iii) uma classe concreta chamada XInst. A interface criada contém as opera¸cões definidas no modelo UML para a entidade. A classe abstrata implementa a interface e especifica seus atributos, bem como seus tipos de dados (por exemplo, Integer,String...) e métodos auxiliares que acessam os atributos, gerados automaticamente pelo ge-rador de código. Por fim, a classe concreta estende a classe abstrata para adicionar os métodos que devem ser implementados para apoiar as opera¸cões da interface. A partir desta etapa, o programador deve preencher os métodos que são gerados vazios, a fim de proporcionar o comportamento da entidade. A classe concreta acessa os atributos das outras classes por meio dos métodos get /set especificados na classe abstrata. Além disso, as associa¸cões entre as classes no modelo UML são representadas por cursores, que são entidades que encapsulam a complexidade da navega¸cão das associa¸cões e atualiza¸cões. O conceito de cursores foi proposto para separar as associa¸cões semânticas das representa¸cões reais e de implementa¸cão.

Uma abordagem de gera¸cão de código baseado em conceitos de MDA foi apresentado por (HAUSMANN; KENT, 2003) para gerar o código-fonte de skeletons a partir de diagramas de classes. A aborda-gem proposta utiliza transforma¸cões baseadas em meta-modelos. Para cada linguagem-alvo, um meta-modelo e as regras de mapeamento do

(45)

PIM para o PSM devem ser especificados. O processo de cria¸cão de regras de mapeamento é baseado nos pares de elementos, em seus relaci-onamentos, em seus dom´ınios e em suas restri¸cões. Cada par representa dois elementos existentes em diferentes modelos. Os modelos estão co-nectados através de um relacionamento que especifica as restri¸cões que devem existir entre os mesmos e a quais elementos elas estão ligadas. O mapeamento entre PIM e PSM é especificado em diagramas de clas-ses aos quais os elementos dos meta-modelos estão ligados por meio de associa¸cões. Para complementar o modelo, restri¸cões OCL adicionais podem ser inclu´ıdas nas associa¸cões. Apesar de não mostrar o c´ odigo-fonte gerado no final, regras de mapeamento de UML para linguagem Java foram retratadas em (HAUSMANN; KENT, 2003). Nota-se que esta abordagem gráfica para descrever as regras de mapeamento podem au-xiliar na visualiza¸cão global da transforma¸cão, no entanto, ela pode dificultar a cria¸cão de mapeamentos mais complexos entre elementos de diferentes modelos.

A formaliza¸cão de classes e diagramas de sequência foi proposto por (LONG et al., 2005), a fim de permitir a gera¸cão do código a partir de modelos UML 2.0. As semânticas dos modelos propostos são baseadas na semântica de Cálculos Relacionais de Objetos de Sistema(rCOs), que foi concebida para projetar sistemas OO. Esse trabalho gera skele-tons de classes Java a partir dos diagramas de classes e códigos para os métodos presentes no diagrama de sequência. O algoritmo de gera¸cão de código interpreta diagramas de sequência como uma composi¸cão de sequências de mensagens, permitindo a sua utiliza¸cão para a cria¸cão de códigos em fragmentos separados. O código-fonte pode ser ge-rado apenas se o modelo passar por uma verifica¸cão de consistência. Nesse trabalho, a gera¸cão de código para a linguagem rCOs é demons-trada, mostrando como os skeletons das classes, contendo os atributos e métodos vazios, são criados. Dependendo do comportamento, cada mensagem nos diagramas de sequência é transformada em uma cha-mada para métodos rCOs. As mensagens são mapeadas para chamadas de métodos no corpo do método pai.

A gera¸cão de código a partir de modelos UML que visam a lin-guagem SystemC é investigada em (ANDERSSON; HöST, 2008). Inicial-mente, o estudo avaliou as constru¸cões de UML 2.0 e SystemC 2.2, e fez uma compara¸cão a fim de criar um mapeamento entre os concei-tos de ambas as linguagens. Considerando a especifica¸cão estrutural, pacotes UML são mapeados para namespaces do SystemC, enquanto nomes, portas e classes ativas da UML são mapeados para módulos do SystemC (a maioria destes conceitos são apresentados em diagramas de

(46)

componentes). No entanto, outros tipos de classes não mencionados são mapeados para classes C++. Na UML, uma porta tem uma interface requerida e uma fornecida que indicam quais sinais enviam e recebem. Por outro lado, em SystemC uma sc port deve ter exatamente uma in-terface, que corresponde à interface requerida da porta UML. A Inter-face fornecida das portas UML é equivalente a constru¸cão de um módulo sc export no SystemC. Em rela¸cão à especifica¸cão da comunica¸cão entre os elementos, na UML a comunica¸cão pode ser modelada como sinais, i.e. mensagens ass´ıncronas, que são enviadas através das portas. O destino é especificado usando conectores. No objeto receptor, o sinal é armazenado em uma fila que, eventualmente, será consumido. Em SystemC, as portas são conectadas através de canais, cuja referência é armazenada na porta durante a inicializa¸cão do sistema. Portanto, para mapear as semânticas mencionadas de UML para SystemC, co-nectores UML são mapeados para canais sc fifo em SystemC que ligam um módulo sc export a outro módulo sc port. Além disso, para pro-duzir códigos fonte em SystemC a partir de modelos UML, o processo de mapeamento é composta por três etapas propostas: (i) a descri¸cão UML inicial é manualmente modelada com um profile que visa a lin-guagem SystemC, (ii) o modelo é transformado em uma nova descri¸cão UML que inclui apenas representa¸cões UML diretas à SystemC, isto é, classes, atributos, heran¸ca, etc. Outras constru¸cões como máquinas de estado são traduzidas para a linguagem-alvo. Durante esta etapa, cada máquina do estado é transformada em uma classe com métodos que implementam o comportamento dos estados e transi¸cões.(iii) o modelo UML produzido na etapa anterior é transformado em códigos SystemC. Esta é uma transforma¸cão de um-para-um em que a gera¸cão de código SystemC foi implementada utilizando um gerador de código C++ da Telelogic Tau (IBM, 2013b), que foi adquirida pela IBM e agora faz parte do Rational Tau (IBM, 2013a). Desta forma, foi poss´ıvel reutili-zar o suporte dado pela ferramenta, as regras de escopo e a inclusão de header-files , bem como realizar a gera¸cão de arquivos sem quaisquer modifica¸cões.

Em (NASCIMENTO et al., 2006) foi proposta uma infra-estrutura de meta-modelos, chamada de ModES (Model-driven Design of Embed-ded Systems), para representar sistemas embarcados distribu´ıdos em tempo real utilizando um n´ıvel maior de abstra¸cão. O objetivo do Mo-dES é fornecer uma infra-estrutura comum a várias ferramentas MDE, como por exemplo, ferramentas de alto n´ıvel que visam a explora¸cão de espa¸co ou a gera¸cão de código. Essa abordagem sugere uma metodo-logia que aplica refinamentos sucessivos a partir de uma especifica¸cão

(47)

inicial, que no caso é um PIM, para um modelo de implementa¸cão do sistema utilizando uma plataforma que foi previamente selecionada. O PIM (que pode ser especificado usando UML, Simulink, ou outras lin-guagens de modelagem) é transformado em um modelo de aplica¸cão que é uma instância de IAMM (Internal Application Meta-Model ), que representa as funcionalidades da aplica¸cão de maneira uniforme. Da mesma forma, modelos de várias plataformas (e.g. SystemC, Java, VHDL, e outros) são especificados usando uma representa¸cão de pla-taforma uniforme chamado IPMM (Internal Platform Meta-Model ). O conjunto de regras de mapeamento é descrito usando o MMM (Mapping Meta-Model ), que é usado para orientar a transforma¸cão dos modelos IAMM e IPMM em um modelo de realiza¸cão do sistema chamado IMM (Implementation Meta-Model ). O IMM representa a implementa¸cão do modelo inicial (ou seja, aquele especificado usando UML, Simulink, etc) usando uma plataforma alvo previamente selecionada (por exemplo, Java, VHDL, SystemC, etc.) onde é gerado o código do IMM.

O framework ModEs foi utilizado em (NASCIMENTO; OLIVEIRA; WAGNER, 2012). Neste trabalho, é apresentado um quadro MDE para melhorar o design de sistemas embarcados. A partir da especifica¸cão funcional da aplica¸cão embarcada, descrita em diagramas UML de clas-ses e de sequência, o framework adota conceitos de MDE para a gera¸cão automática de uma representa¸cão do fluxo de dados e dos controles in-ternos. O modelo obtido capta aspectos estruturais de um modelo de aplica¸cão usando uma hierarquia de módulos e processos, bem como aspectos comportamentais por meio de um CDFG. Se desejado, ele pode ser utilizado por ferramentas de verifica¸cão DSE para otimizar o design. Aplicando as regras de transforma¸cões no modelo UML do sis-tema, uma representa¸cão baseada em MOF é obtida automaticamente através de um mapeamento iterativo durante as transforma¸cões. As transforma¸cões do modelo também possui como entrada um modelo de plataforma, o qual especifica o hardware, os recursos de software e interface e produz um modelo de implementa¸cão. No modelo de imple-menta¸cão, a s´ıntese de software, a s´ıntese de comunica¸cão e algoritmos de s´ıntese de alto n´ıvel são aplicadas para gerar a aplica¸cão final. Além disso, foi definido um meta-modelo DSE, de modo que os espa¸cos no design podem ser facilmente manipulados pelos transformadores MDE usando suas regras de transforma¸cão. Modelos UML/MARTE são usa-dos para gerar as regras de transforma¸cão adicionais, que removem designs inviáveis do projeto.

(48)

3.2 PERFIL E MODELOS UML

Um framework chamado Baobab foi apresentado em ( AKBAL-DELIBAS; BOONMA; SUZUKI, 2009), abordando o DDM para o desenvol-vimento de sistemas para RSSF. Em sua proposta, é descrito um meta-modelo que inclui componentes comportamentais, aspectos funcionais e não funcionais de uma RSSF. Além disso, a DSL exposta no trabalho pode ser estendida pelos desenvolvedores para englobar novos dom´ınios de aplica¸cões e plataformas para RSSF. Esta DSL suporta a inclusão de restri¸cões OCL (Object Constraint Language), o que garante que os modelos gerados serão válidos. Com o framework também é poss´ıvel realizar transforma¸cões de modelos para códigos NesC para TinyOS através do gerador openArchitectureware(OPENARCHITECTUREWARE, 2013).

Em (VICENTE-CHICOTE et al., 2007a) é apresentada uma abor-dagem MDE para o desenvolvimento de aplica¸cões que utilizam uma RSSF. Nela são definidos três n´ıveis de abstra¸cão que permitem aos de-senvolvedores criar: (1) modelos espec´ıficos de dom´ınio, (2) descri¸cões da arquitetura baseada em componentes, e (3) modelos espec´ıficos de cada plataforma. Transforma¸cões automatizadas dos modelos entre esses três n´ıveis de abstra¸cão foram concebidas. Para demonstrar a vi-abilidade da proposta, foi desenvolvido uma aplica¸cão utilizando uma rede de nodos de sensores que utilizam TinyOS(ABCM, 2012), com sen-sores para medir a temperatura da seiva das árvores e um software para controlar a necessidade de irriga¸cão e a transmissão dos dados, que foi implementado na linguagem NesC (GAY et al., 2003). Para de-finir um modelo com possibilidade de reúso e uma maior flexibilidade, foi utilizado o MDE para criar o modelo apresentado na Figura 3.

A DSL, apresentada na Figura 3, inclui tanto caracter´ısticas es-truturais quanto comportamentais da aplica¸cão. A ideia principal é dividir os nodos da aplica¸cão em regiões, que é determinada pela dis-tancia f´ısica entre os nodos. Estas regiões são subdivididas em grupos que determinam os nodos que são responsáveis pela execu¸cão de uma mesma tarefa, estes grupos podem ou não se interligar via um link. O tipo do nodo (E.g. MicaZ, EPOSMoteII) pode ser definido, e cada nodo pode possuir um comportamento que pode ser parametrizado de acordo com as necessidades. Com este modelo, as transforma¸cões M2M e M2T são realizadas e assim é gerado um código em NesC que pode ser aplicado aos nodos da rede.

(49)

Figura 3 – Domain-Specific Language apresentada em ( VICENTE-CHICOTE et al., 2007a).

3.3 GERAÇ ÃO DE C ÓDIGO PARA RSSF

O DSL proposto em (VICENTE-CHICOTE et al., 2007a) é apresen-tado como base e são sugeridas algumas modifica¸cões para aumentar o poder de expressão da DSL em (RODRIGUES et al., 2011). Embora estas propostas sejam semelhantes, alguns elementos ainda não explorados por (VICENTE-CHICOTE et al., 2007a) são analisados. Dentre estes no-vos elementos abordados, podem ser citadas algumas caracter´ısticas da pol´ıtica de economia de energia a ser utilizada, fun¸cões de agrega¸cão de dados, controle de fluxo de opera¸cão da aplica¸cão, hardware, espe-cifica¸cão no envio de dados, representa¸cão de atuadores entre outros considerados muito importantes no desenvolvimentos de um sistema de RSSF. A Figura 4 exibe a DSL proposta por (RODRIGUES et al., 2011) com as modifica¸cões sugeridas.

Além disso, é explorado a gera¸cão de PSMs para diferentes plata-formas que demonstra o comportamento da abordagem para diferentes dom´ınios. Também é explorado o argumento de que a constru¸cão de

(50)

sis-Figura 4 – DSL apresentada em (RODRIGUES et al., 2011).

temas de RSSFs envolve desenvolvedores com diferentes conhecimentos e habilidades, ou seja, especialistas de dom´ınio e especialistas de rede, e é sugerida uma divisão de tarefas entre os especialista no desenvolvi-mento. Outra diferen¸ca é que, enquanto em (RODRIGUES et al., 2011) é adotado uma DSL textual, em (VICENTE-CHICOTE et al., 2007a) é fornecido um editor gráfico para modelagem do aplicativo.

O trabalho citado acima foi usado em (RODRIGUES et al., 2013) para dividir sistemas WSAN em diferentes n´ıveis de abstra¸cão, sendo eles dependentes ou não de plataformas de sensores. A proposta deste trabalho deixa sobre a responsabilidade dos especialistas a concep¸cão de cada n´ıvel, sendo que os artefatos de software desenvolvidos po-dem ser reutilizados ou modificados. Nesta proposta, um framework

(51)

chamado de ArchWiSeN (Architecture for Wireless Sensor and Actu-ator Network ) foi projetado para auxiliar o desenvolvimento de siste-mas WSAN e seus processos de desenvolvimento de software utilizando MDA. ArchWiSeN baseia-se na cria¸cão de modelos UML, podendo in-corporar aspectos estáticos e dinâmicos de software através de diferen-tes diagramas. Sendo que cada diagrama pode representar diferendiferen-tes visões do sistema, há uma melhoria em rela¸cão ao trabalho anterior em (RODRIGUES et al., 2011) pois adota uma especifica¸cão diferente para cada modelo (aplica¸cão, comportamento e customiza¸cão).

De acordo com o trabalho, o ArchWiSeN visa representar o co-nhecimento do dom´ınio de aplica¸cão no n´ıvel PIM. Para isso são utili-zados dois recursos diferentes da UML: os diagramas (os diagramas de classes e atividades) em parceria com um perfil, que destina-se a adicio-nar caracter´ısticas espec´ıficas de WSAN nos modelos. O PIM descreve a semântica dos elementos necessários para construir aplica¸cões WSAN independentemente da plataforma de implementa¸cão. A base que re-presenta as diferentes plataformas de sensores e atuadores é especificada no n´ıvel PSM que novamente utiliza dois diagramas UML diferentes (os diagramas de componentes e de estados finitos).

Uma abordagem para aumentar o n´ıvel de abstra¸cão e integra¸cão entre aplica¸cão, implementa¸cão e a performance de uma RSSF foi pro-posta em (BOONMA; SUZUKI, 2010). O trabalho investiga um nova es-trutura de engenharia de desempenho dirigida a modelo (Model-driven performance engineering) para aplica¸cões de RSSF. O quadro proposto, chamado de MOPPET, destina-se a melhorar a produtividade da im-plementa¸cão de aplica¸cões de RSSF e seu desempenho. O framework MOPPET consiste em dois componentes: Feature modeler (Modela-dor de Caracter´ısticas) e Performance estimator (Estima(Modela-dor de Perfor-mance). O Feature modeler é um ambiente de modelagem gráfica para configurar aplica¸cões de RSSF. Ele aproveita a no¸cão de modelagem para modelar graficamente caracter´ısticas de um aplicativo (e.g. fun-cionalidades e pol´ıticas de configura¸cão) e as restri¸cões entre elas. O Performance estimator foi projetado para estimar o desempenho apro-ximado de um aplicativo RSSF sem gerar o código, nem executá-lo em simuladores ou em RSSFs reais.

Em (SHIMIZU et al., 2011) uma abordagem voltada a DDM é apresentada com base em uma DSL para prototipagem e otimiza¸cão de aplica¸cões para RSSF. Para definir um processo de desenvolvimento foram usados três n´ıveis de abstra¸cão: N´ıvel de Rede, N´ıvel de Grupo e N´ıvel de Nodo. Para cada n´ıvel foram definidas três DSMLs (Do-main Specific Modeling Language) a fim de descrever os modelos nos

(52)

diferentes n´ıveis de abstra¸c˜ao.

O modelo em n´ıvel de rede é independente da rede e descreve o fluxo de dados necessários para cumprir os respectivos requisitos (e.g. tipo de dados que será enviado e recebido, condi¸cões de transmissão, etc). O modelo em n´ıvel de grupo é dependente da rede e descreve a manipula¸cão de um grupo de nodos (cada grupo de nodos é tra-tado como um conjunto de nodos que estão geograficamente próximos uns dos outros e que têm a mesma tarefa) como uma única entidade. Neste modelo são encontradas informa¸cões como amostragem de dados, agrega¸cão de dados, fusão de dados, entre outros. E o modelo em n´ıvel de nodo é dependente da rede e descreve o comportamento de cada nodo. Além disso, o modelo de n´ıvel de nodo expressa a atribui¸cão de tarefas para cada nodo e o link de comunica¸cão entre eles. Cada nodo pode ser expresso como um conjunto de tarefas que devem ser explici-tadas no modelo, como por exemplo, sensoriamento e recebimento de mensagens.

Além das DSMLs, foram definidas regras de transforma¸cão para converter os modelos de alto n´ıvel de abstra¸cão em modelos exe-cutáveis. Assim, as regras de transforma¸cão automática podem auxiliar na gera¸cão do modelo executável a partir do modelo de n´ıvel de rede e fornecer outros pontos de vista para otimizar o desempenho.

Segundo a proposta, o desenvolvedor precisa apenas descrever um modelo usando a DSML referente ao n´ıvel mais alto de abstra¸cão (no caso, seria o n´ıvel de rede). Com isso, as regras de transforma¸cão automaticamente geram o modelo descrito em n´ıvel de grupo e, em seguida, um modelo de n´ıvel de nodo. Durante o processo de trans-forma¸cão são agregados novos elementos com valores fixos pré-definidos nas regras de transforma¸cão. Posteriormente, o desenvolvedor pode criar um modelo executável a partir do modelo de n´ıvel de nodo.

Após a transforma¸cão, existe a op¸cão de promover uma oti-miza¸cão sobre os modelos, onde o desenvolvedor usa o protótipo em um ambiente de execu¸cão e mede a sua performance usando uma ferra-menta de monitoramento. Com base no novo objetivo tra¸cado pelo de-senvolvedor, o novo modelo descrito é automaticamente transformado em modelos mais concretos que darão origem a um modelo executável, gerado de acordo com regras de transforma¸cão.

(53)

3.4 MIDDLEWARE

Uma abordagem a DDM é apresentada em (BUCKL et al., 2008), neste estudo o especialista de dom´ınio deve criar o modelo da aplica¸cão pretendida com base em um meta-modelo que descreve as carac-ter´ısticas relevantes das aplica¸cões de rede de sensores. Com base no modelo, um gerador de código produz o middleware alvo, incluindo as interfaces para a lógica da aplica¸cão. Cada modelo apresentado visa resolver um aspecto particular do middleware ou construir o mid-dleware de outros modelos. A maioria dos modelos implementados são dependentes de plataforma pois eles oferecem uma solu¸cão única para uma determinada combina¸cão de hardware com o sistema opera-cional. Por isso, é necessário uma sele¸cão correta dos modelos. Em vez de implementar um gerador de código próprio, foi utilizada uma estrutura de gera¸cão de código existente, chamada openArchitectu-reWare(OPENARCHITECTUREWARE, 2013).

Para aumentar o n´ıvel de heterogeneidade a proposta utiliza três componentes e dois servi¸cos que se responsabilizam por diferentes par-tes do sistema. O componente Application realiza a fun¸cão de controle da aplica¸cão, enquanto o componente Hardware Interaction se ocupa de fazer a integra¸cão com o hardware e o Node Management monitora o conjunto de nodos, descobrindo novos nodos e realizando o monito-ramento (e.g. estado da bateria ) dos nodos conectados. Para com-plementar as funcionalidades não tratadas pelos componentes existem dois servi¸cos, o Network Service é responsável pela comunica¸cão entre os nodos e o Service Broker é encarregado de controlar para onde as mensagens recebidas são encaminhadas, sendo responsável por toda a lógica de comunica¸cão do aplicativo.

3.5 VISUALIZADORES DE DADOS

Um dos frameworks criados com o objetivo de facilitar a uti-liza¸cão dos usuários finais unindo middlewares à viewers foi explorado em (BUONADONNA et al., 2005). Chamado de TASK, consiste em três n´ıveis:

1. Uma cole¸c˜ao de nodos sensores - Os nodos sensores TASK s˜ao Mica2 ou mica2dot, rodando TinyDB;

2. Um aparelho de rede de sensores (SNA) - serve como um gateway entre a rede de sensores e os clientes. O SNA ´e uma esta¸c˜ao base