Pós-Graduação em Ciência da Computação
TIAGO HEINECK
DESENVOLVIMENTO ORIENTADO A MODELOS
NO DOMÍNIO DE ROBÓTICA: UMA REVISÃO
SISTEMÁTICA DA LITERATURA
Universidade Federal de Pernambuco posgraduacao@cin.ufpe.br www.cin.ufpe.br/~posgraduacao
RECIFE 2016
Tiago Heineck
DESENVOLVIMENTO ORIENTADO A MODELOS NO DOMÍNIO DE
ROBÓTICA: UMA REVISÃO SISTEMÁTICA DA LITERATURA
Dissertação de mestrado apresentada ao Programa de Pós-graduação em Ciência da Computação do Centro de In-formática da Universidade Federal de Pernambuco como requisito parcial para obtenção do grau de Mestre em Ciên-cia da Computação.
Orientador: Jaelson Freire Brelaz de Castro
RECIFE 2016
Catalogação na fonte
Bibliotecária Monick Raquel Silvestre da S. Portes, CRB4-1217
H468d Heineck, Tiago
Desenvolvimento orientado a modelos no domínio de robótica: uma revisão sistemática da literatura / Tiago Heineck. – 2016.
131 f.: il., fig., tab.
Orientador: Jaelson Freire Brelaz de Castro.
Dissertação (Mestrado) – Universidade Federal de Pernambuco. CIn, Ciência da Computação, Recife, 2016.
Inclui referências e apêndice.
1. Engenharia de software. 2. Engenharia de requisitos. 3. Robótica. I. Castro, Jaelson Freire Brelaz de (orientador). II. Título.
005.1 CDD (23. ed.) UFPE- MEI 2017-19
Tiago Heineck
Desenvolvimento orientado a modelos no domínio de robótica: uma
revisão sistemática da literatura
Dissertação apresentada ao Programa de Pós-Graduação em Ciência da Computação da Universidade Federal de Pernambuco, como requisito parcial para a obtenção do título de Mestre Profissional em 13 de dezembro de 2016.
Aprovado em: 13/12/2016.
BANCA EXAMINADORA
_____________________________________________
Prof. Robson do Nascimento Fidalgo Centro de Informática / UFPE
_____________________________________________ Prof. Gilberto Amado de Azevedo Cysneiros Filho
Universidade Federal Rural de Pernambuco
______________________________________________ Prof. Jaelson Freire Brelaz de Castro
Centro de Informática / UFPE (Orientador)
Dedico este trabalho a todos aqueles que superam dificuldades em busca de um objetivo maior.
Agradecimentos
Agradeço e dedico este trabalho a diversas pessoas que de alguma forma contribuíram para a realização do mesmo.
As pessoas do CIn da UFPE que são a parte principal que move o desenvolvimento deste importante centro, em especial aqueles que fazem parte do Laboratório de Engenharia de Requisitos (LER/CIn) pelas valiosas dicas e ensinamentos.
À Secretaria de Educação Tecnológica do Ministério da Educação pelo oferecimento deste programa aos profissionais de tecnologia da informação dos Institutos Federais. Da mesma forma ao Instituto Federal Catarinense que oportunizou a participação deste mestrado contribuindo de todas as formas possíveis, em especial a toda equipe de Tecnologia da Informação do Câmpus Videira pela paciência e apoio.
À meu orientador Jaelson Castro pela liberdade e confiança no desenvolvimento deste trabalho e principalmente pelas contribuições dadas a cada etapa realizada.
Ao meu amigo Enyo Gonçalves que esteve presente em todas as etapas deste projeto, mesmo a distância não mediu esforços para ajudar e chamar a atenção sempre que necessário.
Um agradecimento também a Aêda Souza (UFPE) e Marcos Oliveira (UFC) que estive-ram envolvidos na condução desta pesquisa e a todas as pessoas que avaliaestive-ram o trabalho seja no formato de artigos ou desta dissertação, suas contribuições foram fundamentais.
Aos meus amigos que passaram toda sua motivação e energia, principalmente aos do Vinhedo e aos novos da turma "MPROFSIS2014", não posso deixar de citar aqueles que se tornaram praticamente irmãos, Plínio Garcia e Artur Alves, vocês tornaram essa experiência muito mais divertida.
À minha família, que compreendeu minha ausência por diversas vezes, mesmo com tantas dificuldades que passamos neste período conseguimos resolver tudo. Ao meu pai, que Deus esteja contigo, como você sempre disse, precisamos ser "cada vez melhor"!
Agradeço imensamente minha esposa Lucimara Baroncello, pelo seu amor, compreensão, carinho e incentivo, agora chegou a sua vez!
Enfim, a Deus que me conduziu em segurança nas diversas e demoradas viagens até Recife.
As derrotas de curto prazo, normalmente, nos levam a vitórias permanentes. Aprendemos com os erros, evoluímos no caminho que percorremos até
alcançar nossos objetivos —BENTO AUGUSTO
Resumo
O domínio de robótica tem sido aplicado em diversos contextos, como o industrial, da saúde e da educação, os projetos robóticos envolvem diversos campos de estudo como visão computa-cional, inteligência artificial, psicologia, biologia, entre outros. Na academia competições tem incentivado a construção de robôs que exploram ambientes, jogam futebol e executam tarefas dos mais variados tipos. Estes robôs são agentes compostos de vários sensores e atuadores que trabalham juntamente com software para o alcance de requisitos específicos, sendo o sistema responsável pelo gerenciamento de todos os componentes. Neste sentido, há um subconjunto de robôs conhecidos como robôs sociais que possuem a habilidade de interagir entre eles ou com seres humanos. Estes por sua vez são capazes de reconhecer linguagem natural por meio de fala ou escrita, interpretar gestos e interagir de maneira social e afetiva. Entretanto, o aumento de complexidade dos robôs reflete da mesma forma em softwares de controle mais complexos, deixando a tarefa de desenvolvimento mais desafiadora. Sendo assim, pesquisadores tem apon-tado para o desenvolvimento orienapon-tado a modelos como uma alternativa no auxílio na redução de complexidade do desenvolvimento de software no domínio de robótica. O desenvolvimento orientado a modelos é um paradigma promissor que utiliza modelos como artefatos de primeira ordem que buscam promover o reuso de componentes de software e rápida geração de código com qualidade, consequentemente reduzindo o custo de desenvolvimento e esforço. Assim sendo, esta pesquisa realiza uma análise de como o desenvolvimento orientado a modelos tem apoiado o domínio de robótica, apontando os artefatos disponíveis e gerados semi ou automaticamente, as contribuições, técnicas envolvidas, o atendimento a requisitos funcionais e não-funcionais, paradigmas envolvidos no comportamento do robô e o atendimento a questões sociais. Os dados foram extraídos de 86 estudos compondo uma revisão sistemática da literatura com a finalidade de auxiliar pesquisadores no embasamento para realização de novas atividades de pesquisa.
Palavras-chave: Engenharia de Software. Desenvolvimento Orientado a Modelos. Engenharia de Requisitos. Robótica. Robô Social. Revisão Sistemática da Literatura
Abstract
The field of robotics has been applied in various contexts, such as the industrial, health and education. The robotic projects involve various fields of study such as computer vision, artificial intelligence, psychology, biology, among others. The Academic competitions have encouraged the construction of robots that explore environments, play soccer and perform tasks of various types. These robots are agents made up of multiple sensors and actuators working along with software that meets specific requirements, and the system responsible for the management of all components. In this sense, there is a subset of robots known as social robots that have the ability to interact among themselves or with humans. These in turn are able to recognize natural language through speech or writing, interpreting gestures and interact in social and affective way. However, the increased complexity of robots reflects similarly in more complex control software, leaving the task of development more challenging. Thus, researchers have pointed to the model-driven development as an alternative to assist in the reduction of complexity of software development in the field of robotics. The model-driven development is a promising paradigm that uses models as first order artifacts and seeks to promote the reuse of software components and fast code generation with quality, thus reducing the cost of development and effort. Therefore, this research performs an analysis of how the model-driven development has supported the field of robotics, pointing the available artifacts and semi or automatically generated contributions, techniques involved, the functional and non-functional requirements, paradigms involved in robot behavior and service for social issues. The data was extracted from 86 studies writing a systematic literature review in order to assist researchers in the basement for realization of new research activities.
Keywords: Software Engineering. Model-driven Development. Requirements Engineering. Robotic. Social Robots. Systematic Literature Review
Lista de Figuras 2.1 Arquitetura do Robô . . . 27 2.2 Principais elementos de MDD . . . 30 2.3 Arquitetura de metamodelagem . . . 31 2.4 MDD em um relance . . . 32 3.1 Etapas realizadas . . . 41 3.2 Etapas da pesquisa . . . 48
4.1 Distribuição Temporal dos estudos . . . 56
4.2 Tipo de publicação . . . 56
4.3 Tipo de Robôs . . . 58
4.4 Aplicação e casos de uso . . . 59
4.5 Principais benefícios identificados . . . 60
4.6 Comparativo de componentes com outros técnicas . . . 61
4.7 Tipos de modelos . . . 62
4.8 Principais artefatos disponíveis . . . 62
4.9 Contribuições de MDD - Transformação . . . 65
4.11 Artefatos gerados . . . 65
4.10 Geração de código . . . 66
4.12 Tipos de Requisitos . . . 69
4.13 Frequência de publicação envolvendo requisitos não-funcionais . . . 70
4.14 Catálogo On-line: tela inicial . . . 77
4.15 Catálogo On-line: sugestão de artigos . . . 77
Lista de Tabelas
3.1 Valores para avaliação de qualidade . . . 49
3.2 Quantidade de estudos e pontuações de qualidade . . . 50
4.1 Local de Publicação . . . 57
4.2 Trabalhos mais citados . . . 57
4.3 Autores com mais publicações . . . 58
Lista de Acrônimos
CBD Component Based Software Development . . . 36
CPC Componente-Porta-Conector . . . 34
CIM Computation Independent Model . . . 31
DSL Domain Specific Language . . . 34
IEEE Institute of Electrical and Electronics Engineers . . . 27
LER Laboratório de Engenharia de Requisitos . . . 18
IFR International Federation of Robotics . . . 22
FR Requisitos Funcionais . . . 28
M2T Modelo para Texto . . . 32
M2M Modelo para Modelo . . . 32
MDA Model-Driven Architeture . . . 31
MDD Model-Driven Development . . . 15
MDE Model-Driven Engineering . . . 31
MDS Model-Driven Security . . . 21
MSL Mapeamento Sistemático da Literatura . . . 37
NFR Requisitos não-funcionais . . . 28
OMG Object Management Group . . . 31
PIM Platform Independent Model . . . 31
PSM Platform Specific Model . . . 32
RSL Revisão Sistemática da Literatura . . . 18
SOA Service-Oriented Architecture . . . 36
TR Teleo-reativo . . . 18
UFPE Universidade Federal de Pernambuco . . . 52
UML Unified Modeling Language . . . 35
Sumário 1 Introdução 15 1.1 Contexto . . . 15 1.2 Motivação . . . 16 1.3 Objetivos . . . 18 1.4 Metodologia . . . 19 1.4.1 Aprendizado do método . . . 21 1.5 Estrutura de Capítulos . . . 21 2 Embasamento Teórico 22 2.1 Robótica . . . 22 2.1.1 Robótica Social . . . 25
2.1.2 Questões comportamentais do Robô . . . 26
2.2 Especificação de Requisitos . . . 27
2.3 Desenvolvimento Orientado a Modelos . . . 28
2.3.1 Desenvolvimento Orientado a Modelos no domínio da Robótica . . . . 34
2.4 Trabalhos Relacionados . . . 36
2.5 Considerações sobre o capítulo . . . 38
3 Método 40 3.1 Estrutura da Questão de Pesquisa . . . 41
3.2 Questões de Pesquisa . . . 42
3.3 Estratégias de Busca . . . 45
3.3.1 Seleção de Fontes de Busca . . . 45
3.3.2 Fonte de Busca . . . 45
3.3.3 Termos de busca . . . 45
3.3.3.1 Resultados esperados . . . 45
3.3.4 Documentação do Processo de Busca . . . 46
3.3.4.1 String de Busca . . . 46
3.4 Seleção dos Estudos . . . 47
3.4.1 Critérios de Inclusão e Exclusão . . . 47
3.5 Processo de Seleção dos Estudos Primários . . . 47
3.6 Avaliação de Qualidade dos Estudos . . . 49
3.7 Extração dos dados . . . 50
3.8 Fluxo de Condução . . . 52
3.9 Ameaças a Validade . . . 53
4 Resultados e Discussões 55
4.1 Visão Geral . . . 55
4.1.1 Considerações da Visão Geral . . . 58
4.2 Q1: Análise de características . . . 59
4.2.1 Benefícios e Técnicas Envolvidas . . . 59
4.2.2 Artefatos e transformações . . . 61
4.2.3 Frameworks e Simuladores . . . 66
4.2.4 Considerações sobre as características . . . 67
4.3 Q2: Tipos de requisitos envolvidos . . . 68
4.3.1 Considerações da Q2 . . . 70 4.4 Q3: Questões Comportamentais . . . 71 4.4.1 Considerações sobre a Q3 . . . 74 4.5 Q4: Questões Sociais . . . 74 4.5.1 Considerações sobre a Q4 . . . 75 4.6 Catálogo On-Line . . . 76 4.7 Considerações do capítulo . . . 78 5 Conclusão 79 5.1 Contribuições da pesquisa . . . 81 5.2 Questões em Aberto . . . 81 5.3 Trabalhos Futuros . . . 82 5.4 Considerações Finais . . . 83 Referências 84 Apêndice 96 A Apêndice 97
15 15 15
1
Introdução
Este capítulo apresenta uma visão geral do trabalho, tendo seu conteúdo organizado como segue.
Contexto: o contexto da pesquisa é apresentado, delimitando as áreas e conceitos em que o trabalho é relacionado;
Motivação: são expostos os fatores no qual motivam a realização do estudo;
Objetivos: os objetivos gerais e específicos são expostos;
Metodologia: os artefatos metodológicos utilizados são apresentados;
Estrutura do Trabalho: expõe uma visão geral dos demais capítulos da dissertação.
1.1 Contexto
O desenvolvimento orientado a modelos (Model-Driven Development - MDD) é uma técnica de desenvolvimento de software que consiste da aplicação de modelos com o objetivo de simplificar e formalizar diversas atividades e tarefas do ciclo de desenvolvimento de software, aumentando o nível de abstração em que os desenvolvedores os criam (HAILPERN; TARR, 2006). Modelos também são utilizados para especificar requisitos em sistemas complexos, contribuindo para redução de ambiguidades de linguagem natural (SOARES; VRANCKEN, 2007).
Para Brambilla, Cabot e Wimmer (2012), Model-Driven Development (MDD) é um paradigma de desenvolvimento que usa modelos como artefatos de primeira ordem no processo desenvolvimento, onde a implementação é gerada (semi) automaticamente a partir deles. Selic (2003), por sua vez, aponta que umas das principais vantagens é que modelos são expressados usando conceitos menos ligados a implementação e mais relacionados ao domínio do problema, tornando assim mais fáceis de especificar, entender e manter.
Um dos campos de aplicação de MDD tem sido a robótica. Brugali (2015) indica que o uso de modelos pode ter um alto impacto no ciclo de desenvolvimento de sistemas robóticos, podendo incorporar o conhecimento de especialistas de vários domínios tanto científicos quanto
1.2. MOTIVAÇÃO 16 tecnológicos, como por exemplo, mecânica e ciências cognitivas, apoiando a transição automática do espaço do problema para o espaço de solução. De fato o domínio de robótica é caracterizado pela fusão de uma grande gama de tecnologias (BROGÅRDH, 2007).
Ainda na década de noventa sistemas robóticos foram propostos com várias configurações e aplicados para muitas tarefas, especialmente para operar em ambiente dinâmico, onde a incerteza e mudanças não previstas podem acontecer tanto a robôs como a outros agentes, adicionando características comportamentais de reatividade ou deliberação ao sistema robótico (IOCCHI; NARDI; SALERNO, 2001).
A utilização de robôs tem sido realizada em diversos domínios, como no industrial (BROGÅRDH, 2007), médico (BOGUE, 2011) e na educação (HAN et al., 2005). Eles podem ser classificados em robôs industriais ou de serviço (International Federation of Robotics, 2016). Além destes, surgem oportunidades envolvendo robôs sociais que interagem com seres humanos de maneira natural, ou seja, aderindo normas sociais, estabelecendo comunicação em alto nível de diálogo, expressando e interpretando emoções, entre outros (KIRBY; FORLIZZI; SIMMONS, 2010). Companhias de todo o mundo estão fabricando este último tipo para diversas situações, como: segurança, entretenimento e cuidados com a saúde (KIDD; TAGGART; TURKLE, 2006). Sendo assim, o escopo abordado neste trabalho envolve a proposta ou o uso de técnicas ou abordagens de MDD no apoio ao domínio de robótica. Onde técnicas e abordagens correspondem de maneira mais geral a linguagens, ferramentas, frameworks de modelagem e processos de transformação.
Neste sentido, realizamos uma revisão da literatura buscando características relacionadas ao envolvimento destas duas áreas. Adicionalmente, dentro desta interseção, são observados três pontos, sendo: (1) os tipos de requisitos especificados, sendo funcionais ou não-funcionais; (2) questões comportamentais que envolvem os estilos arquiteturais relacionados a agentes inteligentes, que são classificados de maneira geral em reativos, deliberativos e híbridos e (3) questões sociais, envolvendo aspectos da relação do robô com o ambiente, com pessoas ou outros robôs, reproduzindo comportamentos sociais de humanos, como emoções, coletividade e outros.
Todas estas áreas que compõe o trabalho são apresentadas em mais detalhes na Seção 2 (Referencial Teórico).
1.2 Motivação
O desenvolvimento de software na robótica tem sido um desafio, pois os sistemas robóticos estão cada vez mais complexos, exigindo múltiplos sensores distribuídos no corpo do robô e assim incorporando tarefas mais complexas. Portanto o aumento de funcionalidades dos robôs provoca um aumento na complexidade a nível de software (BRUYNINCKX et al., 2013).
Devido as dificuldades, o uso de MDD é apontando como uma das principais correntes para o auxílio no processo de desenvolvimento de software no domínio de robótica. A comu-nidade de engenharia de software está se movendo nessa direção, pois ajuda aos especialistas
1.2. MOTIVAÇÃO 17 de domínio a mudar o foco da implementação para o problema. Permitindo que o sistema seja analisado de forma mais eficiente (RAMASWAMY; MONSUEZ; TAPUS, 2014a).
O conhecimento de especialistas em vários domínios científicos e tecnológicos (como mecânica e ciências cognitivas) podem ser incorporados em modelos. Em seguida, podem ser transformados do espaço do problema para o espaço de solução, apoiados por ferramentas. Causando um alto impacto no ciclo de desenvolvimento de um sistema de software robótico (BRUGALI, 2015).
Alguns dos benefícios que MDD oferece ao domínio de robótica incluem os mencionados a seguir.
Um metamodelo permite definir conceitos que são importantes para o projeto. As ferramentas podem auxiliar na fácil criação e manipulação dos modelos (IBORRA et al., 2009);
Técnicas de transformação de modelos em código permitem o apoio a um processo de desenvolvimento semi ou automático. Os modelos são especializados de um alto nível de abstração e transformados (IBORRA et al., 2009);
Conceitos de comunicação, computação, comunicação, configuração e coordenação podem ser separados em níveis diferentes de abstração dos modelos (RAMASWAMY; MONSUEZ; TAPUS, 2014a);
Utilizado em conjunto com o desenvolvimento baseado em componentes promove reuso de software. Os componentes podem ser integrados permitindo a rápida customização de sistemas robóticos (BRUYNINCKX et al., 2013);
Permite a separação de papéis omitindo detalhes que não são relevantes para um papel específico. (SCHLEGEL; STECK; LOTZ, 2011).
Estas evidências foram visualizadas em uma revisão da literatura ad hoc, onde estudos que propõe o uso de MDD em robótica foram identificados. Dois deles, a linguagem RobotML (DHOUIB et al., 2012) e o framework de modelagem SmartSOFT (SCHLEGEL et al., 2015), foram escolhidos para análise tendo um projeto robótico já existente como base.
Partindo do documento de especificação de requisitos e dos manuais de ambas foram criados modelos de acordo com os diagramas disponibilizados. Os autores também foram contatados para verificação dos modelos e sugestão de correções. O objetivo foi conhecer e aplicar com o intuito de gerar código. O framework de modelagem SmarSOFT apresentou um resultado positivo, pois os modelos foram criados e os esqueletos de código gerados com facilidade. De outro lado, RobotML permitiu a criação dos modelos de maneira simples, mas não foi possível a geração de código. Os resultados foram apresentados em grupos focais com a participação de pesquisadores do domínio de robótica. Foram discutidas as dificuldades de desenvolvimento de software nesta área.
1.3. OBJETIVOS 18 A partir deste estudo inicial e de discussões realizadas por pesquisadores do Laboratório de Engenharia de Requisitos (LER) algumas questões foram observadas no desenvolvimento de software robótico, como por exemplo: foco maior em programação, problemas com padronização de código e pouca relação com etapas que compõe a engenharia de software. Sendo assim, existe o interesse destes pesquisadores em contribuir para melhoria no processo de desenvolvimento de software neste domínio.
Surge então a necessidade de uma busca sistemática na literatura para um entendimento mais amplo sobre o uso das técnicas de engenharia de software em robótica, mais especificamente de MDD. É necessário identificar as contribuições proporcionadas pelas técnicas, bem como aumentar o entendimento sobre como estes modelos tem apoiado o processo de desenvolvimento neste domínio. Esta análise pode auxiliar pesquisadores na seleção de estudos, possibilitando o embasamento, escolha de linguagens e ferramentas. Também podem ser utilizados como base para novos estudos.
Outros pontos de dúvida foram discutidos, um deles é sobre os tipos de requisitos de software (funcionais ou não-funcionais) que têm sido atendidos pelas abordagens. De acordo com Pressman (2011) os requisitos devem ser bem especificados para que seja criada uma solução que atenda as necessidades e que não tenha ambiguidades. Sendo assim é importante que o software robótico seja bem especificado, este ponto pode ser diferencial na execução correta do que é pretendido no robô.
Decidir o paradigma no qual se baseará o modo de agir também é algo que permeia o desenvolvimento de sistemas robóticos, que podem ser identificados de maneira abrangente como reativos e pró-ativos, influenciando na arquitetura interna do agente (robô) (MURPHY, 2000). Modelos também são utilizados para representar estas arquiteturas. Por exemplo, Morales et al. (2015) apresentam uma linguagem de modelagem para especificação de requisitos em sistemas Teleo-reativo (TR), que tem como principal vantagem reagir de forma robusta as mudanças em seus ambientes, apresentam um caso de estudo baseado em um projeto de futebol de robôs.
Por fim, um último ponto de dúvida é verificar se alguma das linguagens ou técnicas atende questões sociais como normas, emoções, regras, entre outros, analisando se MDD pode estar sendo utilizado para modelagem e geração de código que atendam estes quesitos.
Este trabalho além de necessário para aumento do embasamento dos pesquisadores inte-ressados é um ponto de partida, sendo importante para que sejam tomados novos direcionamentos para trabalhos empíricos que apoiem o desenvolvimento de software no domínio de robótica e robôs social.
Partindo da motivação os objetivos estão são definidos e apresentados na Seção 1.3.
1.3 Objetivos
O objetivo principal deste trabalho é contribuir para o melhor entendimento dos trabalhos que propõe o uso de MDD em robótica por meio de uma Revisão Sistemática da Literatura (RSL).
1.4. METODOLOGIA 19 Este levantamento integra evidências de maneira quantitativa para aumento do embasamento sobre o tema e auxílio no desenvolvimento de novos estudos, oferecendo uma visão geral sobre as contribuições e aplicação de cada técnica em trabalhos relacionados ao domínio de robótica, bem como fornecer indícios de padronizações e características importantes para a tomada de decisão.
Apoiando o objetivo principal, foram definidos os seguintes objetivos específicos: Verificar as características presentes nos trabalhos de MDD, tais como: benefícios
propostos, áreas relacionadas, tipos de artefatos utilizados e produzidos, tipos de modelos, entre outros.
As características estão relacionadas a itens observados na execução da pesquisa, levantando evidências que apontem quais deste é mais ou menos importante em detrimento a outro.
Identificar os tipos de requisitos atendidos, fazendo um levantamento entre funcionais e não-funcionais.
Modelos de MDD ou até mesmo código refletem requisitos que são definidos. A análise deste item não pretende verificar se o trabalho apoia as fases da engenharia de requisitos, mas sim quais deles tem sido mais apoiados no processo de desenvolvi-mento de software robótico guiado por modelos.
Identificar a relação com questões comportamentais do robô.
O foco aqui é observar paradigmas relacionados com a área de agentes inteligentes, sendo ligado a maneira como o robô reage ao ambiente e a estímulos, identificando quais paradigmas e técnicas são mencionadas nas pesquisas de MDD em robótica. Verificar a existência de técnicas que atendam questões sociais em robótica.
O desenvolvimento de robôs sociais pode estar sendo apoiado por técnicas específicas de MDD, permitindo lidar com emoções, regras e normas sociais, coletividade e outros. Analisando esse ponto é possível verificar se novas oportunidades podem ser trabalhadas especificamente para este tipo de robôs.
Os objetivos norteiam a definição das questões de pesquisa da RSL, expostas com suas justificativas na Seção 3.2, juntamente com a metodologia e detalhes do protocolo da RSL.
1.4 Metodologia
Este trabalho executa uma RSL para aumentar o conhecimento a respeito da utilização de técnicas de MDD no domínio de robótica. Para tal é utilizado um protocolo produzido a partir do guia de Kitchenham e Charters (2007), amplamente referenciado na engenharia de software
1.4. METODOLOGIA 20 baseada em evidências. Segundo os autores as razões para uma revisão sistemática da literatura são:
Resumir evidências existentes, apontando benefícios e limitações;
Identificar pontos nas pesquisas atuais propondo novos estudos;
Prover um background para novas atividades de pesquisa.
Os mesmos autores apresentam um guia de lições aprendidas (BRERETON et al., 2007), onde indicam que o objetivo da Engenharia de Software Baseada em Evidências é prover meios para que evidências atuais possam ser integradas na experiência prática e apoiar a tomada de decisão no desenvolvimento e manutenção de software.
Zhang e Baber (2011) definem que a RSL é uma maneira de identificação, avaliação e combinação de evidências de estudos primários usando um método bem definido, sendo larga-mente utilizada em áreas como a medicina e sociologia, além disso, buscam o relacionamento com a questão de pesquisa, a área tópico ou o fenômeno.
Esta revisão da literatura é classificada de acordo com a taxonomia de Cooper (RAN-DOLPH, 2009) e apresentada no Quadro 1.1.
Quadro 1.1: Quadro Metodológico
Características Descrição
Foco Práticas ou Aplicações
Objetivo Integração/Generalização
Perspectiva Representação Neutra
Abrangência Exaustiva
Organização Metodológica
Audiência Público Acadêmico
Fonte: o autor.
A escolha do foco em práticas ou aplicações é motivado pelo objetivo geral deste trabalho considerando o apoio dado pela intervenção de MDD no domínio de robótica, com o intuito de integrar estes dados fornecendo uma visão geral das características encontradas.
Quanto a perspectiva é considerada neutra pela intenção de representar os dados apresen-tados de fato ao máximo, para tal mecanismos que possibilitem a redução de viés são aplicados, como por exemplo, execução em pares, revisões e formulários padronizados.
Este trabalho tem uma abrangência exaustiva devido considerar todas as peças. Porém Randolph (2009) aponta que este fator pode demandar mais tempo que o disponível, sendo assim recomenda a definição de uma população. Neste caso são optados por artigos publicados em revistas e periódicos indexados em bases de dados científicas e que atendam uma string de busca definida.
A organização é metodológica, apresentando sua introdução, seu método e resultados por meio de um relatório (RANDOLPH, 2009), sendo destinado a acadêmicos especializados
1.5. ESTRUTURA DE CAPÍTULOS 21 que buscam mais informações a respeito dos assuntos por ele abordado, sendo este contido nesta dissertação.
O método com todos os seus artefatos são apresentados em detalhes no Capítulo 3.
1.4.1 Aprendizado do método
Após a escolha da metodologia uma busca foi realizada para encontrar estudos sobre a aplicação de uma RSL e que auxiliam na montagem do protocolo, verificando que na engenharia de software são utilizados dois guias: (1) Kitchenham e Carters (2007) apresentam um relatório derivado de outros guias utilizados na medicina e ciências sociais e promovendo discussões com pesquisadores envolvidos com práticas baseadas em evidência. (2) Biolchini et al. (2005) criaram um relatório sobre o assunto, apresentando exemplos da medicina por ser a área em que este tipo de estudo surgiu e é amplamente utilizado, são apresentados os processos e fases e os artefatos a serem seguidos para o desenvolvimento deste tipo de estudo.
Uma leitura de estudos que utilizam RSL em engenharia de sofware foi realizada refor-çando o entendimento sobre a utilização do método, são exemplos: (1) Dermeval et al. (2015) relacionado a ontologias e requisitos, (2) Loniewski et al. (2010) sobre MDD e engenharia de requisitos e (3) Nguyen et al. (2015) relacionado a Model-Driven Security (MDS).
Em paralelo ao planejamento deste projeto foi realizado outro estudo utilizando a mesma metodologia, sendo parte do trabalho de doutorado de Enyo Gonçalves (UFC/UFPE).
1.5 Estrutura de Capítulos
Os demais capítulos desta dissertação estão estruturados em cinco partes, sendo elas apresentadas a seguir.
No Capítulo 2 é apresentado o embasamento teórico utilizado como base para o desenvol-vimento desta pesquisa, expondo os conceitos de Robótica, Robótica Social, Desenvoldesenvol-vimento Orientado à Modelos, Especificação de Requisitos, Questões Sociais e Comportamentais. Por fim, os trabalhos relacionados são identificados e comparados com este.
Em seguida, no Capítulo 3 é exposto o método de RSL adotado no processo de pesquisa, detalhando o protocolo definido e as etapas planejadas. São definidas as questões de pesquisa, os critérios de inclusão e exclusão, critérios de qualidade e formulários de extração.
Prosseguindo, o Capítulo 4 apresenta as descobertas resultantes dos dados extraídos a partir de estudos obtidos no processo de condução da RSL. Os dados são apresentados e discutidos com a utilização de gráficos e tabelas. Sendo assim, as respostas as questões de pesquisa são realizadas.
Por fim, no Capítulo 5 as conclusões e considerações finais são apresentados, enfatizando as descobertas e apontando trabalhos futuros.
Os materiais utilizados para o apoio a construção deste trabalho são incluídos no Apên-dice, como a lista de estudos, análise de qualidade e formulários utilizados.
22 22 22
2
Embasamento Teórico
Nesta seção são apresentados os conceitos que embasam a temática deste trabalho, iniciando pelo domínio de robótica e robótica social, fazendo uma ligação com desenvolvimento de software, especificação de requisitos e desenvolvimento orientado a modelos.
2.1 Robótica
Um robô pode ser uma máquina que executa tarefas repetitivas, sejam guiadas, prede-finidas ou de maneira inteligente, sendo capaz de perceber o ambiente e realizar a tomada de decisão (ROMERO et al., 2014). Para operar em ambientes dinâmicos o mesmo deve ser capaz de utilizar e coordenar seus recursos computacionais e físicos de maneira eficaz (SIMMONS, 1994).
No contexto industrial a principal razão para adoção de robô é a possibilidade de redução de custo de produção. Muitos dispositivos podem ser controlados por apenas um controlador e diversas unidades podem trabalhar em paralelo evitando inclusive acidentes como colisão. Por exemplo, a indústria automotiva tem feito uso em tarefas que também envolve perigo como soldagem (BROGÅRDH, 2007).
Outra aplicação é feita na área da saúde, onde o aumento da população idosa e a escassez de pessoal especializado para atendimento tem estimulado o desenvolvimento envolvendo áreas como cirurgias e próteses. Como exemplo, utilizando braços robóticos por neurocirurgiões para remoção de tumores do cérebro (BOGUE, 2011).
A International Federation of Robotics (IFR) (2016) caracteriza robôs conforme a ISO-8373:2012, apresentado a seguir:
1. Robô industrial: um manipulador de múltiplo propósito, reprogramável, controlado automaticamente, programável com três ou mais eixos, sendo fixo ou móvel para uso em aplicação de automação industrial;
2. Robô de serviço: mecanismo programável em dois ou mais eixos com um grau de autonomia, movendo-se em um ambiente e realizando tarefas específicas úteis para seres humanos ou excluindo aplicação de automação industrial;
2.1. ROBÓTICA 23 3. Robô pessoal de serviço ou robô para uso pessoal: é um robô de serviço usado para tarefas não comerciais, como cadeira de roda automatizada, assistente de mobilidade pessoal, servente doméstico e outros;
4. Robô para uso profissional: é um robô de serviço para tarefas comerciais, usualmente controlado por um operador treinado em iniciar, monitorar e parar, como robôs de limpeza, de combate a incêndio, serviço de entrega, entre outros.
Em robôs industriais, temos como exemplo os modelos de braços robóticos desenvolvidos pela empresa Kuka Robotics (Kuka Robotics, 2016). São exemplos de robôs de serviço os robôs móveis Robotnik AGVS (ROBOTNIK, 2016), uma plataforma para transporte em ambientes internos.
O desenvolvimento destes robôs é multidisciplinar, integrando conhecimentos de En-genharia Mecânica, Elétrica, Mecatrônica e da Computação, sendo este último responsável pela inteligência da máquina, por sua vez composta de diversos componentes como sensores, atuadores e um sistemas de controle (ROMERO et al., 2014).
Os sensores são mecanismos utilizados para extração de informação sobre o ambiente ou a respeito do próprio robô, possibilitando assim que o mesmo estime seu deslocamento baseado nos dados percebidos. Já os atuadores refletem na capacidade de realizar ações em ambientes, provido por motores e partes mecânicas que compõem braços robóticos, garras e rodas por exemplo (ROMERO et al., 2014).
Sistemas robóticos compreendem em um grande número de dispositivos embarcados que devem trabalhar corretamente de maneira segura. O desenvolvimento dos mesmos implica no uso de técnicas de análise formal para garantir a corretude dos requisitos, implicando na adoção de padrões que auxiliem no alcance de confiabilidade e tolerância a falha. Em geral o projeto de sistemas robóticos podem integrar conhecimento e ferramentas de diferentes domínios da enge-nharia (SÁNCHEZ et al., 2011). Por estas razões e devido a complexidade do domínio e grande variedade de hardware, o reuso de software tem sido um tópico muito popular (MAKARENKO; BROOKS; KAUPP, 2007).
Os software robóticos são concorrentes, distribuídos, embarcados, em tempo real e sensíveis a dados. Um dos maiores requisitos é a performance, especialmente em robôs autô-nomos que processam um grande número de informações presentes em sensores. Brugali e Prassler (2009) apresentam algumas considerações sobre as metodologias de desenvolvimento de software neste domínio, como segue.
A principal corrente de Engenharia de Software compreende em componentes de software, middleware, frameworks e desenvolvimento orientado a modelos;
A engenharia de software habilita a construção de novos softwares pela composição de componentes e reuso de arquiteturas de alto-nível e blocos de software;
2.1. ROBÓTICA 24
A adoção de técnicas de engenharia em robótica permite facilidade para pesquisadores em manter partes de código sem a necessidade de constantemente reescrevê-los; O reuso de software em robótica é um grande desafio. Os sistemas são construídos
por pesquisadores para propósitos experimentais variando muito em finalidade. Uma das maneiras de reuso também se dá com a utilização de frameworks, apoiando a construção de software neste domínio, alguns deles são citados a seguir.
ROS (Robot Operation System), sendo um framework flexível para escrita de software robótico, contém uma coleção de ferramentas, bibliotecas e convenções para simplificar a tarefa de criar sistemas complexos e robustos para uma grande variedade de plataformas robóticas (Open Source Robotics Foundation, 2016).
OROCOS (Open Robot Control Software) também é um framework proposto para a criação de software robótico, sendo baseado em componentes e podendo ser utilizado por diversos fornecedores de plataformas. Possui bibliotecas escritas em C++ para controle de robôs e máquinas avançadas e um conjunto de ferramentas para apoiar a construção dos mesmos (OROCOS, 2016).
Schlegel e Wör (1999) apresentam o framework SmartSoft para implementar sistemas robóticos, não somente contendo componentes de software mas também regras estruturais e templates em uma arquitetura de sistemas multicamadas. Busca facilitar o processo de implementar e integrar novos módulos em sistemas complexos provendo o reuso de software em diversas plataformas móveis.
O trabalho de desenvolvimento de software pode ser apoiado por simuladores. Harris e Conrad (2011) apresentam em seu estudo uma relação de alguns específicos para robótica, afirmando que estes tem a capacidade e flexibilidade de simular diversas plataformas robóticas usando mecanismos similares aos utilizados em jogos, alguns exemplos são apresentados a seguir.
Um projeto de simulação é Gazebo, que torna possível testes rápidos de algoritmos, projetos de robô e avaliação de performance em cenários realísticos, possibilitando simulação de população de robôs em ambientes internos e externos (GAZEBO, 2016).
O Microsoft Robot Studio (MICROSOFT, 2016) fornece também uma ferramenta de simulação embutida em sua plataforma de desenvolvimento para robótica, que é apoiada por diversas plataformas como Festo Robotino, Lego Mindstorn e Pionner 3DX.
Outras técnicas vêm sendo utilizadas com o mesmo objetivo. Por exemplo, o mento baseado em componentes também promove reuso, acelerando o processo de desenvolvi-mento. Este paradigma compreende em artefatos de software que são reutilizáveis (IBORRA et al., 2009). Se enfatiza a construção de componentes de prateleira, que são unidades individuais permitindo a composição por terceiros. Portanto, prometem o benefício de aumento de reuso, redução de custo e agilidade no lançamento de novas composições de sistemas (SCHLEGEL; HASSLER, 2009).
2.1. ROBÓTICA 25 2.1.1 Robótica Social
Um robô social é um (semi) autônomo que interage e se comunica com humanos seguindo regras sociais ligadas ao seu papel (KAHN JR et al., 2004), estes robôs devem possuir características humanas como: expressar e perceber emoções, comunicação em alto nível de diálogo, aprender modelo de outros agentes, estabelecer relações sociais, exibir personalidade e caráter e aprender competências sociais (FONG; NOURBAKHSH; DAUTENHAHN, 2003). Os modelos Nao e Romeo da SoftBank (Softbank Robotics, 2016) são exemplos de robôs sociais.
Os robôs sociais ou socialmente interativos variam em forma e função, cada um com uma proposta, respeitando algumas normas sociais para aumento do desempenho no ambiente humano (FONG; NOURBAKHSH; DAUTENHAHN, 2003). Breazeal (2003) define subclasses para robôs sociais, sendo elas:
Socialmente evocativo: projetada para encorajar pessoas a antropomorfizar a tecno-logia interagindo com ela. É bastante comum em brinquedos, produzindo interações divertidas, instigando ao ser humano sensibilidade social mas não retribuído pelo robô.
Interface social: robôs que usam questões sociais como humanos e modalidades de comunicação que facilitam a interação com seres humanos. Tornando a mesma mais familiar e natural.
Socialmente receptivo: este tipo também beneficia a interação humana, envolvendo robôs que aprendem a interagir com pessoas por meio de demostração humana, como aquisição de habilidades motoras, de linguagem e até mesmo cognitivas, sendo mais perceptivo a questões sociais humanas.
Sociáveis: são criaturas socialmente participativas tendo objetivos e motivações internas, agem de maneira pró-ativa envolvendo as pessoas de maneira social para beneficiá-las mas também para beneficiá-lo. Eles percebem não somente as interfaces da iteração mas também modelam pessoas em termos sociais. Sendo um produto computacional que envolve a psicologia social.
Estes trabalhos embasam sobre questões sociais envolvidas no domínio de robótica, que estão relacionados nesta dissertação com habilidades e competências sociais de seres humanos e animais. Olhando para a psicologia, Scassellati (1999) descreve competência social como uma característica individual que leva em conta a interação de um indivíduo com outros.
Com base nestes estudos é possível ter um entendimento sobre questões sociais, não se limitando a elas, mas servindo como uma guia inicial de referência, algumas são citadas na lista que segue.
Emoções e afetividade: expressar ou perceber emoções e agir de forma afetiva com seres humanos;
2.1. ROBÓTICA 26
Normas Sociais: cumprir normas, regras e leis;
Coletividade: agir de maneira colaborativa para realizar determinada tarefa ou apre-sentar engajamento, por exemplo, futebol de robôs;
Aprendizado: aprender com outros agentes, sejam robóticos, humanos ou animais;
Comunicação e diálogo: se comunicar com humanos e outros robôs.
2.1.2 Questões comportamentais do Robô
Os comportamentos de robô podem ser definidos em deliberativo e reativo, no primeiro caso existe uma decomposição de tarefas em sub-tarefas que especificam as atividades atuais e futuras deles, no segundo caso o sistema detecta e responde diretamente ao estímulos do seu ambiente. (SIMMONS, 1994)
A questão comportamental do robô é relacionada com as arquiteturas internas de agente, que são paradigmas da inteligência artificial que classificam esse tipo de comportamento. Para Russel e Norvig (2003), a arquitetura interna determina propriedades, atributos, componentes mentais e comportamentos, definidas de forma básica em pró-ativo (baseado em objetivos ou baseado em utilidade) e reativo (reativo simples ou reativo baseado em conhecimento).
Outra classificação para estilos arquiteturais é apresentada por Coste-Maniere e Sim-mons (2000), sendo: (1) Hierárquico: adota uma abordagem top/down, tendo a supremacia de um controle de alto nível e restringindo a comunicação horizontal nos nível mais baixos; (2) Comportamental: com uma abordagem bottom-up, usando grupos de módulos conhecidos como “behaviors” executando concorrentemente e interagindo por meio de comunicação; (3) Híbrido: combina as anteriores para controle reativo e deliberativo em uma arquitetura heterogênea. Os autores mencionam algumas arquiteturas e argumentam sobre decomposição baseado em abstração de tarefas.
De outro lado, Murphy (2000) apresenta uma relação entre inteligência artificial e robótica, que relaciona as três categorias apresentadas a seguir e representadas na Figura 2.1, sendo as definições das entradas e saídas de cada uma. Apresentadas no Quadro 2.1.
1. Reativo: o robô reage diretamente ao ambiente;
2. Deliberativo ou hierárquica: o robô recebe entrada de sensores e passa por um plano correspondente a uma modelo de mundo antes da saída ser dada por atuadores; 3. Híbrido: combina característica das duas anteriores, tendo um plano pré-estabelecido
2.2. ESPECIFICAÇÃO DE REQUISITOS 27
Figura 2.1: Arquitetura do Robô
PERCEPÇÃO PLANO AÇÃO
PERCEPÇÃO AÇÃO PERCEPÇÃO PLANO AÇÃO
Deliberativo
Reativo
Híbrido
Fonte: adaptado de Murphy (2000)
Quadro 2.1: Definição dos termos de entradas e saídas
Primitivos do Robô Entrada Saída
PERCEPÇÃO Dados de sensores Informação
PLANO Informação (percebida e/ou cognitiva) Diretivas
AÇÃO Informação ou diretivas Comandos do atuador
Fonte: traduzido de Murphy (2000) pelo autor.
2.2 Especificação de Requisitos
O Institute of Electrical and Electronics Engineers (IEEE) apresenta o padrão 830 (IEEE, 2011) que define a Engenharia de Requisitos (RE) como uma técnica que media o contato entre comprador e fornecedor para estabelecer e manter os requisitos necessários para o sistema, software ou serviço de interesse, concentrando-se na descoberta, elicitação, desenvolvimento, análise, validação, comunicação, documentação e gerenciamento de requisitos.
O objetivo da Engenharia de requisitos é determinar as propriedades que um sistema deve ter para obter sucesso, sendo algumas vezes relativamente simples e outras não. Contudo, diversos fatores aumentam a dificuldade como questões sociais, políticas ou culturais (GOGUEN, 1993).
A tarefa de especificar requisitos é parte da Engenharia de Requisitos, que segundo Pressman (2011) fornece um mecanismo apropriado para entender o que o cliente deseja por meio de análise de necessidades, viabilidade e especificando uma solução sem ambiguidades.
Especificação de requisitos é uma coleção estruturada de requisitos de um software como funções, restrições, atributos (IEEE, 2012). O IEEE também define como uma especificação para um software, programa ou conjunto de programas que realizam determinadas funções em um ambiente específico, sendo escrito por um ou mais representantes do fornecedor ou do cliente
2.3. DESENVOLVIMENTO ORIENTADO A MODELOS 28 ou de ambos (IEEE, 1998).
Os requisitos de software são divididos em duas categorias: Requisitos Funcionais (FR) capturando a natureza da interação entre o componente e o ambiente, já os Requisitos não-funcionais (NFR) abordam os tipos de soluções que se pode considerar, ou seja, fatores adicionais para o atendimento de requisitos funcionais, como segurança e desempenho (ROMAN, 1985).
Van Lamsweerde (2009) apresenta uma definição clara a respeito dos requisitos, onde os requisitos funcionais definem os efeitos funcionais do software em seu ambiente, abordando quais aspectos estão envolvidos, como por exemplo: "o software de controle do trem deve controlar a aceleração de todos os trens do sistema". Esses requisitos também podem se referir a condições do ambiente em que as operações são aplicadas.
Para requisitos não-funcionais o mesmo autor apresenta uma lista de categorias que envolve os seguintes itens: requisitos de qualidade, safety, segurança, confidencialidade, inte-gridade, disponibilidade, confiabilidade, desempenho, usabilidade, arquitetura (distribuição e implantação), desenvolvimento (custo, portabilidade), entre outros.
Uma das formas de representação de requisitos é utilizando modelos, como por exemplo: diagramas de classes que representam entidades, seus atributos e seus relacionamentos; diagramas de caso de uso para obter as operações entre atores e funcionalidades de um sistema; e diagramas de estado de máquina que especificam o comportamento de componentes por meio de transições de uma sequência de estados (VAN LAMSWEERDE, 2009).
2.3 Desenvolvimento Orientado a Modelos
O que define o MDD é seu foco principal em desenvolvimento de modelos ao invés de programas de computador, possuindo a vantagem de expressar modelos utilizando conceitos menos ligados a tecnologia de implementação, aproximando do domínio do problema em relação às linguagens de programação (SELIC, 2003).
Para Herfs et al. (2013) o MDD é uma paradigma que foca na representação do co-nhecimento como modelos de domínio e por usa vez, esses modelos permitem a separação da especificação do problema dos detalhes de implementação e por fim, podem ser transformados em códigos executáveis.
A proposta de MDD é que o engenheiro de software concentre-se em modelos de alto nível invés de interagir diretamente com o código-fonte, protegendo-se da complexidade das implementações de cada plataforma. Desta forma modelos passam a fazer parte do software e não meramente como artefatos de documentação. LUCRÉDIO (2009) apresenta as principais vantagens do uso de MDD. São apresentadas a seguir.
Produtividade: melhoria no tempo de desenvolvimento. Tarefas repetitivas são implementadas nas transformações, poupando tempo e esforço que podem ser usados em tarefas mais importantes;
2.3. DESENVOLVIMENTO ORIENTADO A MODELOS 29
Portabilidade: códigos podem ser gerados para diferentes plataformas a partir de um mesmo modelo;
Interoperabilidade: cada parte do modelo pode ser transformado em código para uma plataforma diferente e podem ser gerados adaptadores independentes de plata-forma para que os códigos possam se comunicar;
Manutenção e Documentação: em processos convencionais os modelos são
uti-lizados como artefato inicial e depois são abandonados. Já em MDD os modelos fazem parte do software, então são mantidos atualizados de acordo com o software produzido;
Comunicação: modelos podem ser utilizados para facilitar a comunicação entre os envolvidos no projeto. Os especialistas de domínio participam mais ativamente do processo, utilizando modelos para identificar os conceitos de negócio. Os es-pecialistas de computação podem utilizar dos mesmos identificando os aspectos técnicos.
Reuso: Os modelos podem ser reutilizáveis em projetos diferentes, onde o próprio código-fonte pode ser re-gerado para o novo contexto;
Verificações e otimizações: verificadores semânticos podem ser utilizados para reduzir a ocorrência de erros. Fornecendo implementações mais eficientes;
Corretude: geradores de código podem evitar erros de digitação ou outros que poderiam ser introduzidos por um desenvolvedor.
Algumas desvantagens também são apontadas (LUCRÉDIO, 2009), como segue.
Rigidez: o código do software produzido pode ficar fora do alcance do desenvolvedor quando grande parte dele é gerado;
Complexidade: uma complexidade adicional é introduzida ao processo, visto que são necessárias ferramentas para modelagem, transformação e geração de código. Os artefatos dos modelos são mais difíceis de construir e manter;
Desempenho: em alguns casos os geradores incluem código desnecessário, resul-tando assim em perda de desempenho;
Curva de aprendizado: MDD exige muita habilidade na construção de artefatos específicos para linguagens, ferramentas de modelagem e mecanismos de transforma-ção. Não é muito difícil mas exige treinamento;
2.3. DESENVOLVIMENTO ORIENTADO A MODELOS 30
Alto investimento inicial: a construção de uma infra-estrutura para que modelos possam ser produzidos e reutilizados demanda de investimento em tempo e esforço. Porém gera futuros benefícios também relacionados a tempo e esforço.
Um ponto importante de uma linguagem de modelagem é a definição de um meta-modelo, sendo uma abstração que reflete as propriedades de um modelo, ou seja, constituem na definição de uma linguagem de modelagem, definindo classes, atributos e relacionamentos (BRAMBILLA; CABOT; WIMMER, 2012). O metamodelo é utilizado como uma referência em ferramentas de modelagem na construção de modelos, apoiando também nas ferramentas que definem os mecanismos de transformação de modelos em outros modelos ou em código-fonte (vide Figura 2.2).
Figura 2.2: Principais elementos de MDD
Fonte: LUCRÉDIO (2009)
A representação dos modelos, como por exemplo de UML, pode ser vista em uma arquitetura de 4 camadas. Os níveis são descritos a seguir conforme apresentado por Ameller (2009) e demostrados na Figura 2.3.
M3: contém os metadados que descrevem as propriedades que
meta-metadados podem exibir, esta camada é auto descrita. Para esta camada a OMG define uma linguagem chamada MOF (Meta Object Facility), uma ideia aproximada é de um diagrama de classes muito limitado;
M2: esta camada contém os meta-metadados que descrevem propriedades que
metadados podem exibir. Como exemplo temos os elementos de UML como Classe, Atributo e Operação. Os metamodelos são encontrados aqui e descrevem uma linguagem de maneira bem definida em forma de um modelo;
M1: nesta camada estão os metadados da aplicação, como as classes dos sistemas orientados a objetos;
M0: corresponde aos dados da aplicação, ou seja, as instâncias de um sistema orientado a objetos em tempo de execução.
2.3. DESENVOLVIMENTO ORIENTADO A MODELOS 31
Figura 2.3: Arquitetura de metamodelagem
Meta-metamodelo <<metametaclasse>>MetaClasse
Metamodelo Modelo Dados <<metaclasse>> Classe Produto Farinha Legenda: descreve instância de
M3
M2
M1
M0
Fonte: adaptado de LUCRÉDIO (2009) e AMELLER (2009)
Os modelos podem ter vários tipos, como exemplo a UML, que define uma taxonomia para os tipos de modelos. O primeiro é o estrutural onde seus constructos são utilizados para modelar as propriedades de entidades em um ponto específico de tempo. São exemplos os diagramas de classe, componente e implantação. Por outro lado os modelos comportamentais são utilizados para modelar como estas propriedades mudam ao longo do tempo. São exemplos os diagramas de estado, atividade e sequência (OMG, 2015).
Modelos funcionais também são encontrados na literatura, sendo utilizados para descrever funções e processos. Alguns exemplos são os diagramas de bloco funcional, diagrama de fluxo de bloco funcional e diagrama de fluxo de dados (RUMBAUGH et al., 1991). Algumas ferramentas que suportam esse tipo de modelagem são Matlab e Simulink (RAHMAN et al., 2013).
Do ponto de vista da Object Management Group (OMG), são definidos alguns conceitos baseados em MDD, como Model-Driven Engineering (MDE) que descreve uma técnica de desenvolvimento de software proposta para aumento da qualidade de software, bem como a Model-Driven Architeture (MDA) que descreve níveis de modelagem. A MDA pode ser dividida em etapas e os artefatos gerados em cada uma delas possuem um nível de independência para um melhor aproveitamento (KLEPPE; WARMER; BAST, 2003). Os conceitos de cada uma destas fases estão ilustrados na Figura 2.4 e descritos de acordo com Pastor et al. (2008) na sequência.
Computation Independent Model (CIM): se concentra no entendimento de requisitos para especificar o domínio da aplicação.
Platform Independent Model (PIM): define as entidades do sistema e seus relacio-namentos, a arquitetura do projeto, mas sem detalhes de implementação, ou seja, as
2.3. DESENVOLVIMENTO ORIENTADO A MODELOS 32 Figura 2.4: MDD em um relance
CIM
CIM
M2M
M2M
M2T
CIM
PIM
CIM
PSM
CIM
CÓDIGO
class MyClass { int MyVar; private MyMethod(){ return ‘nothing’; } }Fonte: adaptado de Ameller (2009)
partes do sistemas que são computacionais.
Platform Specific Model (PSM): descreve o sistema atendendo características especí-ficas da plataforma que será suportada.
A transição de um modelo CIM para PIM e de PIM para PSM são realizados por um processo de transformação chamado de modelos para modelos (M2M), enquanto de um modelo PSM para o código é chamado de modelo para texto (PASTOR et al., 2010), este último sendo muito importante e utilizado para implementação de código e geração de documentação (ROSE et al., 2012), sendo ela total ou parcial. A OMG definiu o modelo MOF2Text buscando a padronização da transformação de modelo em texto, especificando um template com placeholders (marcadores) para serem extraídos dos modelos (OMG, 2008).
Biehl (2010) explica que o Modelo para Texto (M2T) transforma elementos de um modelo em fragmentos de texto, caso o texto produzido seja código-fonte também é chamado de "model-to-code". Já o tipo de transformação Modelo para Modelo (M2M) cria elementos em um modelo alvo, mapeando elementos de um modelo-fonte.
A criação de ferramentas de modelagem e transformação são realizadas por ecossistemas que possuem essa finalidade. Elas são apoiadas por iniciativas da OMG, Eclipse e outras. A
2.3. DESENVOLVIMENTO ORIENTADO A MODELOS 33 OMG como já mencionado anteriormente possui a visão própria de MDA, que possui como base o MOF que serve como meta-metamodelo para definição de todas as linguagens de modelagem.
Além do MOF, os modelos podem ser representados em XML, definidos na visão de MDA como XMI (XML Metadata Interchange). O formato define a estrutura do documento considerando a relação entre os dados e seus correspondentes. Permitindo que uma ferramenta identifique os metadados que descrevem os dados que estão sendo lidos. Os níveis de M0 a M3 podem ser representados. Já o QVT (Queries/Views/Transformations) é uma outra visão de MDA que permite definir regras de mapeamento entre modelos escritos em uma linguagem de modelagem. O QVT define uma linguagem textual e uma notação para consultas e transformações baseadas em MOF (LUCRÉDIO, 2009).
Uma outra técnica, mantida pela IBM, é baseada na plataforma Eclipse. O EMF (Eclipse Modeling Framework) permite a manipulação de modelos correspondentes a um meta-metamodelo chamado Ecore. Um outro projeto baseado em Eclipse se destaca, o GMT (Genera-tive Modeling Tools), o mesmo possui mecanismos similares aos de MDA. Três exemplos podem ser citados: (1) a ATL (Atlas Transformation Language), uma linguagem para definição de transformações entre modelos; (2) MOF Script, contemplando ferramentas para transformações de modelos para texto e (3) Textual Concrete Sintax, que permite a definição de DSLs textuais (SOUSA, 2012).
Modelos não necessariamente precisam ter transformação, invés disso um engenho (do inglês engine) genérico é implementado, interpretando e executando os modelos dinamicamente. Este procedimento é chamado em MDD de interpretação de modelo. Brambilla, Cabot e Wimmer (2012) caracterizam pelas seguintes propriedades e vantagens:
aumenta a agilidade não exigindo uma etapa de geração de código;
permite alterar o modelo em tempo de execução sem parar a aplicação;
habilita portabilidade sendo que um interpretador pode ser criado para diversas plataformas
Além da interpretação, os modelos também podem ser executáveis, sendo assim classifi-cados quando as operações semânticas são completamente especificadas, na prática a executabi-lidade de um modelo depende mais da adoção do engenho de execução do que de um próprio modelo (BRAMBILLA; CABOT; WIMMER, 2012).
Outro paradigma foi proposto, trata-se do Models@Run.time. Os modelos são produ-zidos em um nível elevado de abstração, muito próximo ao espaço do problema. O uso deles em tempo de execução pode auxiliar na correção de erros de projeto ou melhores decisões de projetos em nível de execução para suportar o controle contínuo do projeto. Em outras palavras, a ideia é manter conectados modelos de desenvolvimento com os modelos de execução, trazendo a perspectiva que um modelo em tempo de execução pode ser visto como um modelo de
desen-2.3. DESENVOLVIMENTO ORIENTADO A MODELOS 34 volvimento vivo, habilitando evolução dinâmica dos projetos de software (BLAIR; BENCOMO; FRANCE, 2009).
2.3.1 Desenvolvimento Orientado a Modelos no domínio da Robótica
No domínio da Robótica, o uso de algumas técnicas de MDD foram propostas, algu-mas delas implementadas e disponibilizadas. São apresentadas a seguir as propostas BRICS, RobotML, SmartSOFT e V³CMM.
O framework de modelagem SmartSOFT propõe ferramentas para o atendimento do ciclo completo de desenvolvimento de um robô, focando em padrões de comunicação que atuam dentro de serviços na borda de componentes, define uma Domain Specific Language (DSL) para descrever os objetos de comunicação que são transmitidos a outros componentes por meio destes serviços (STECK; LOTZ; SCHLEGEL, 2011).
Modelos são utilizados na criação de componentes, gerando esqueletos de código chama-dos de component hull, estabelecendo padrões para comunicação entre os mesmos por meio de portas na borda de cada componente, funcionando como serviços. Os padrões de comunicação definidos são: send, query, push newest, push time, state, wiring patterns e event patterns, cada um com uma função específica.
Inicialmente os modelos são criados como componentes em um modelo independente de plataforma (PIM), refinados posteriormente com informação específica de plataforma. Na fase seguinte um modelo de descrição de plataforma é utilizado para ligar os componentes formando um modelo de implantação. Então os modelos são transformados em código-fonte.
BRICS trabalha com MDD e separação de conceitos, tendo sua sintaxe representada pelo meta-modelo Componente-Porta-Conector (CPC), onde os componentes representam computa-ção e as portas representam o tipo de comunicacomputa-ção (BRUYNINCKX et al., 2013). A sintaxe do modelo é representada por um meta-modelo de Componente-Porta-Conector (CPC) e a semântica é mapeada como componentes que representam a computação e são hierarquicamente compostos, contendo um coordenador que inicia e finaliza cada componente. A comunicação é feita por meio de portas que podem ser conectadas respondendo a eventos e chamadas de serviços.
A arquitetura estrutural é definida usando componentes, portas e conectores. Cada componente contém um coordenador que é definido com uma máquina de estado. O código executável é gerado para middlewares ROS e Orocos.
A linguagem de modelagem RobotML é desenvolvida pelos pesquisadores do projeto PROTEUS. Seu modelo consiste em meta-modelos de arquitetura, comunicação, comportamento e implantação, utilizando da mesma forma que o BRICS, de um modelo CPC. Sua ferramenta permite acoplar padrões para geração de código para diversos frameworks (DHOUIB et al., 2012).
O modelo arquitetural define o projeto estrutural usando o modelo CPC e define o ambiente, tipos de dados e plataforma. Já o modelo de comunicação define o tipo de comunicação
2.3. DESENVOLVIMENTO ORIENTADO A MODELOS 35 e o fluxo de dados e portas de serviço. O modelo de comportamento é definido utilizando máquinas de estados, onde atividades específicas são associadas com estados e transições e mapeadas em algoritmos específicos. Finalmente, um modelo de implantação especifica um conjunto de componentes definindo cada componente para uma middleware robótico ou simulador. A transformação gera código executável.
O V³CMM consiste em um meta-modelo de componente com as visões estrutural, de coordenação e algorítmica. A visão estrutural define uma estrutura estática de componentes, a coordenação descreve comportamentos orientados por eventos e a visão algorítmica descreve o código executado por cada componente (RAMASWAMY; MONSUEZ; TAPUS, 2014a).
Na visão estrutural os componentes, portas, interfaces e interconexões são definidos. Para o modelo de coordenação são utilizadas máquinas de estados da UML e a visão algorítmica faz uso dos diagramas de atividade também da UML. Inicialmente os tipos de dados e interfaces são definidos, para depois criar os diagramas de cada visão. No final do processo as atividades são vinculadas as máquinas de estado e estas aos componentes. São utilizadas duas transformações, a primeira gerando modelos UML e a segunda transformando os mesmos em código executável. Os trabalhos mencionados utilizam a plataforma do Eclipse (http://www.eclipse.org) para o desenvolvimento de suas ferramentas baseadas em um meta-modelo provido pelo EMF (Eclipse Modeling Framework). Outras características em comum também são percebidas, como a separação de conceitos, separação de papéis, reuso de componentes e padrões de comunicação.
Na questão de transformação, todas utilizam M2T para geração de código executável, possuindo algumas variações tanto no processo de transformação, quanto nos códigos gerados (RAMASWAMY; MONSUEZ; TAPUS, 2014a).
Ramaswamy, Monsuez e Tapus (2014a) apresentam os quatro estudos anteriores, re-sumindo o fluxo de funcionamento e algumas características. Ao final os autores propõem e posicionam o seu framework SafeRobots no ecossistema de MDD, onde o mesmo encon-trasse em estágio inicial de desenvolvimento. Em outro estudo dos mesmos autores (2014b) são apresentados cenários de exemplo e as características atendidas pelo SafeRobots, que em muito se iguala aos demais. Porém, divide em modelos funcionais para satisfação dos requisitos comportamentais do sistema e modelos não funcionais satisfazendo requisitos não-funcionais e atributos de qualidade do sistema.
Carvalhaes et al. (2013) utilizam de modelos SysML, um perfil de Unified Modeling Language (UML). Incluindo em diagramas os atributos de emoções baseados em EmotionML (W3C, 2016). Utilizam como base para criar um robô que demostra emoções. Porém, os modelos não são estendidos e fazem parte do processo de análise de software somente, sem transformações automáticas ou semi-automáticas dos mesmos em outros modelos ou em código-fonte.
Algumas características do uso de MDD incluem: (a) separação de papéis: onde usuários podem ser construtores de componentes, usuários finais, integradores de sistemas, comunidade robótica, entre outros. (b) separação de conceitos: é a separação dos conceitos relacionados as funcionalidades do software, sendo os 5Cs que envolvem comunicação, computação,
coordena-2.4. TRABALHOS RELACIONADOS 36 ção, configuração e composição (DHOUIB et al., 2012).
2.4 Trabalhos Relacionados
Alguns trabalhos similares foram desenvolvidos, sendo os mesmos apresentados nesta seção, todos possuem questões e análises diferenciadas, porém podem ser utilizados em conjunto para entendimento e uma melhor tomada de decisão no desenvolvimento de novas atividades dos domínios relacionados.
No trabalho de Pons, Giandini e Arévalo (2012) foi realizada uma revisão sistemática da literatura relacionada ao uso de técnicas avançadas de engenharia de software no domínio de Robótica e o nível de automatização das mesmas, sintetizando informação tendo como objetivo identificar lacunas e sugerir novas áreas de investigação. As questões definidas pelos autores buscam verificar se MDD, Component Based Software Development (CBD) e Service-Oriented Architecture (SOA) tem sido aplicados no desenvolvimento de sistemas robóticos e qual a tendência, além disso, verifica o uso das mesmas de maneira combinada ou de forma isolada, finalizando com uma busca de quais técnicas de MDE tem sido aplicadas e qual o nível de automação.
Os estudos foram selecionados a partir de buscas automáticas em 3 bases científicas, sendo IEEE, ACM e Scopus, esta última trata-se de um indexador e os autores mencionam que não contribuiu com novos resultados. Foram analisados 195 artigos publicados entre 1999 e o início de 2011, restando 67 para extração. Relacionado a MDD são identificados 21 estudos, desta relação 7 deles tratam apenas de MDD, 12 também relacionados a CBD, 2 a SOA, além de 1 com as três técnicas. Os itens analisados e resultados são apresentados no Quadro 2.2
Quadro 2.2: Itens de MDD analisados por Pons et al.
Características analisadas Resultados
Linguagem de modelagem 64% criação de DSL, 27% são perfis de UML e 9%
diagra-mas de UML
Criação de ferramenta 65% utilizam ferramenta existentes enquanto 35% criam
uma ferramenta
Nível de automação 55% completa, 27% média e 18% baixa
Fonte: Pons, Giandini e Arévalo (2012)
As conclusões apontam que a utilização de técnicas existentes auxiliam na economia de tempo e esforço no desenvolvimento de sistemas robóticos, bem como identificam o aumento na tendência de publicações relacionadas as três técnicas no domínio de robótica, embora as mesmas tenham sido aplicadas em sua maioria isoladamente.
Esta dissertação se difere indo especificamente na relação de MDD e robótica, porém a string utilizada foi seguida como base removendo os termos relacionados a CBD e SOA e adicionando novos termos de MDD. O número de bases científicas pesquisadas foi dobrada e o período expandido até o início de 2016 (em 5 anos), como os autores apontam apenas 2 estudos
