Pós-Graduação em Ciência da Computação
“AvComponent: Um Framework para Desenvolvimento de Componentes de Realidade Virtual em Infraestrutura
de Compartilhamento de Componentes em Nuvem” Por
Daniel Abella Cavalcante Mendonça de Souza
Dissertação de Mestrado
Universidade Federal de Pernambuco [email protected] www.cin.ufpe.br/~posgraduacao
RECIFE 2014
UNIVERSIDADE FEDERAL DE PERNAMBUCO
CENTRO DE INFORMÁTICA
PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO
DANIEL ABELLA CAVALCANTE MENDONÇA DE SOUZA
“AvComponent: Um Framework para Desenvolvimento de
Componentes de Realidade Virtual em Infraestrutura de
Compartilhamento de Componentes em Nuvem”
ESTE TRABALHO FOI APRESENTADO À PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO DO CENTRO DE INFORMÁTICA DA UNIVERSIDADE FEDERAL DE PERNAMBUCO COMO REQUISITO PARCIAL PARA OBTENÇÃO DO GRAU DE MESTRE EM CIÊNCIA DA COMPUTAÇÃO.
ORIENTADOR: Prof. Dr. Fernando da Fonseca de Souza CO-ORIENTADOR: Prof. Dr. Marcus Salerno de Aquino
RECIFE 2014
Catalogação na fonte
Bibliotecária Jane Souto Maior, CRB4-571
S729a Souza, Daniel Abella Cavalcante Mendonça de
AvComponent: um framework para desenvolvimento de componentes de realidade virtual em infraestrutura de compartilhamento de componentes em nuvem / Daniel Abella Cavalcante Mendonça de Souza. – Recife: O Autor, 2014.
86 f.: il., fig., quadro
Orientador: Fernando da Fonseca de Souza.
Dissertação (Mestrado) – Universidade Federal de Pernambuco. CIn, Ciência da computação, 2014.
Inclui referências.
1. Ciência da computação. 2. Engenharia de software. 3. Computação em nuvem. 4. Realidade virtual. I. Souza, Fernando da Fonseca de (orientador). II. Título.
004 CDD (23. ed.) UFPE- MEI 2015-50
Dissertação de Mestrado apresentada por DANIEL ABELLA CAVALCANTE
MENDONCA DE SOUZA à Pós-Graduação em Ciência da Computação do Centro de
Informática da Universidade Federal de Pernambuco, sob o título “AvComponent: Um
Framework para Desenvolvimento de Componentes de Realidade Virtual em Infraestrutura de Compartilhamento de Componentes em Nuvem” orientada pelo Prof. Fernando da Fonseca de Souza e aprovada pela Banca Examinadora formada pelos
professores:
______________________________________________ Prof. André Luis de Medeiros Santos
Centro de Informática/UFPE
______________________________________________
Prof. Gabriel de França Pereira e Silva
Departamento de Estatística e Informática / UFRPE
_______________________________________________ Prof. Fernando da Fonseca de Souza
Centro de Informática / UFPE
Visto e permitida a impressão. Recife, 27 de novembro de 2014.
___________________________________________________
Profa. Edna Natividade da Silva Barros Coordenadora da Pós-Graduação em Ciência da Computação do Centro de Informática da Universidade Federal de Pernambuco.
AGRADECIMENTOS
Ao professor Fernando da Fonseca de Souza, pela confiança e pela colaboração durante a execução deste trabalho e ao professor Marcus Salerno de Aquino, pela contribuição na minha inserção na área acadêmica, assim como acompanhamento durante todo este percurso.
À Deus, por ter colocado na trajetória da minha vida, pessoas maravilhosas como minha esposa, Nathaly Abella, meus pais, Eurípedes Sebastião e Elisa Abella, e o meu irmão, Felipe Abella.
Aos meus amigos professores e alunos da faculdade iDez (Estácio de Sá), em especial aos professores Jaildo Pequeno, Karoline Lira e Gerson Domingos.
Por fim, aos meus amigos, Edvalson Ribeiro, Tibério Lúcio, Paulo André (Paulão), Max Davis, Eder Ferreira, Ryan Ribeiro, César Rocha e Rodrigo Fujioka.
RESUMO
Cenários tridimensionais construídos com técnicas de RV estão sendo usados em sistemas nas mais diversas áreas, em especial em educação. Entretanto, durante o processo de criação, os ambientes tridimensionais, assim como os componentes de software desenvolvidos estão destinados à plataforma criada. Com intuito de permitir o compartilhamento de componentes em RV, sejam ambientes tridimensionais ou componentes de software, é apresentado o framework AvComponent, que permite aos mais diversos sistemas na área compartilhar seus componentes, assim como obter outros componentes, podendo ainda aprimorá-los. Para contemplar esta necessidade, técnicas de Desenvolvimento Baseado em Componentes foram desenvolvidas, em associação com ferramentas de Computação nas Nuvens, em especial o Banco de Dados nas Nuvens.
Palavras chaves: 1. Computação nas nuvens. 2. Engenharia de software. 3. Reuso de software. 4. Realidade virtual
ABSTRACT
Tridimensional scenarios built with Virtual Reality techniques are being used in systems in several areas, especially in education. However, during the creation process, tridimensional environments and developed software components are limited to the platform it was originally created. In order to allow sharing of components in Virtual Reality area (tridimensional environments or software components), is presented the AvComponent framework that allows several systems in the area share their components as well as obtain or improve other components. To address this need, Component-based Development techniques were developed in association with Cloud Computing tools, especially Cloud Databases.
Keywords: 1. Cloud computing. 2. Software engineering. 3. Software reuse. 4. Virtual reality
LISTA DE FIGURAS
Figura 1: Apresentação do Jogo Second Life
Figura 2: Camadas de Software no Java 3D
Figura 3: Relação das Características Essenciais, Modelos de Serviço e Modelos de
Implantação
Figura 4: Características Essenciais de Cloud Computing
Figura 5: Modelos de Serviço
Figura 6: Exemplo de Aplicativos no Modelo Software as a Service (SaaS)
Figura 7: Exemplo de Ambientes no Modelo Platform as a Service (PaaS)
Figura 8: Relacionamento entre os Modelos de Implantação
Figura 9: Estrutura Básica de um Banco de dados como Serviço
Figura 10: Classificação de Banco de Dados nas Nuvens
Figura 11: Disseminação das primeiras ideias sobre reuso de software
Figura 12: Processo de Desenvolvimento de Software baseado em DBC proposto por
Sommerville
Figura 13: Arquitetura do NRVA
Figura 14: Ambiente do TSS
Figura 15: Ambiente do ViMeT
Figura 16: Representação do Processo de Desenvolvimento Scrum
Figura 17: Arquitetura do AvComponent
Figura 18: Relação das Tecnologias e Frameworks envolvidos no Desenvolvimento
Figura 19: Arquitetura Interna do Browser
Figura 20: Processo de Associação de uma Task ao Browser
Figura 21: Representação gráfica da estrutura do descritor de implantação
Figura 23: Implementação Mínima para uma Task
Figura 24: Resultado da associação de uma Task simples
Figura 25: Processo de Solicitação de um Ambiente em Base Interna
Figura 26: Arquitetura do VEPersonal
Figura 27: Arquitetura do VEPersonal após integração com o AvComponent
Figura 28: Processo de Solicitação de uma Task
Figura 29: Apresentação de um Ambiente pelo VEPersonal
Figura 30: Ambiente Apresentado pelo VEPersonal com TouchSensor Mapeado pelo
AvComponent
Figura 31: Apresentação de uma Task do AvComponent no VEPersonal
Figura 32: Demonstração do Módulo de Modelagem Visual de Agentes com o
LISTA DE QUADROS
Quadro 1: Obstáculos e Oportunidades em Cloud Computing
Quadro 2: Requisitos chave para um SGBD nas nuvens
Quadro 3: Benefícios e Dificuldades na Abordagem de Reuso de Software
Quadro 4: Requisitos para Estruturação de um Repositório de Componentes
Quadro 5: Comparativo entre as Ferramentas Analisadas
Quadro 6: Relação dos Papéis e Responsabilidades no Processo Scrum
Quadro 7: Exemplo válido de um descritor de implantação para o browser
Quadro 8: Parte do Ambiente X3D para o Processo de Associação de uma Task ao
Browser
Quadro 9: Arquivo browser.xml para Processo de Associação de uma Task ao Browser
LISTA DE ABREVIAÇÕES
AV: Ambientes Virtuais
AVA: Ambiente Virtual Adaptativo API: Application Programming Interface BD: Banco de Dados
CC: Cloud Computing
DBC: Desenvolvimento Baseado em Componentes DSL: Domain Specific Languages
DSVL: Domain Specific Visual Language EAD: Ensino a Distância
EC2: Amazon Elastic Cloud Computing ES: Engenharia de Software
GP: Gerência de Projetos
IAAS: Infrastructure as a Service JPA: Java Persistence API
MOR: Mapeamento Objeto-Relacional
NIST: National Institute of Standards and Technology OTAN: Organização do Tratado do Atlântico Norte OO: Orientação a Objetos
PAAS: Platform as a Service
PMK: Project Management Knowledge RV: Realidade Virtual
SL: Service Locator
SAAS: Software as a Service
SGBD: Sistemas de Gerenciamento de Banco de Dados SMA: Sistema Multi-Agente
TI: Tecnologia da Informação
TSS: Transformer Substation Simulation
VEPERSONAL: Personalized Virtual Environment VPN: Virtual Private Network
VRML: Virtual Reality Model Language X3D: Extensible 3d
XML: eXtensible Markup Language XP: Extreme Programming
SUMÁRIO
1
Introdução ... 14
1.1 Motivação ... 15 1.2 Objetivos ... 16 1.3 Organização do Trabalho... 162
Referencial Teórico ... 18
2.1 Realidade Virtual ... 182.1.1 Representação de Objetos Tridimensionais ... 21
2.1.2 Armazenamento de Objetos Tridimensionais ... 22
2.2 Computação nas Nuvens (Cloud Computing) ... 24
2.2.1 Características Essenciais ... 26
2.2.2 Modelos de Serviço ... 28
2.2.3 Modelos de Implantação ... 31
2.2.4 Tendências da Cloud Computing ... 33
2.3 Banco de Dados nas Nuvens (Cloud Databases) ... 33
2.3.1 Categorias ... 35
2.4 Engenharia de Software ... 36
2.4.1 Reuso de Software ... 37
2.5 Trabalhos Relacionados ... 41
2.5.1 NRVA ... 42
2.5.2 Java Adaptive Dynamic Environment ... 43
2.5.3 Transformer Substation Simulation (TSS) ... 44
2.5.4 Virtual Medical Training (ViMeT) ... 44
2.6 Conclusões ... 45
3
AvComponent: Um Framework para Desenvolvimento de Componentes
de Realidade Virtual em Infraestrutura de Compartilhamento de Componentes
em Nuvem ... 47
3.1 Metodologia de Desenvolvimento ... 47
3.2 Arquitetura de Software ... 49
3.2.1 Tecnologias ... 51
3.2.2 Módulo Cliente (Browser) ... 52
3.2.3 Módulo Servidor ... 59
3.3 Testes ... 60
3.4 Considerações Finais ... 62
4
Aplicação do Framework para Reuso de Ambientes na Ferramenta
VEPersonal ... 63
4.1 Ferramenta VEPersonal ... 63
4.2 Processo de Integração com o VEPersonal ... 64
4.3 Execução do Cenário do Estudo de Caso ... 66
4.4 Avaliação do Cenário do Estudo de Caso ... 68
5
Conclusões e Trabalhos Futuros... 71
5.1 Contribuições ... 71
5.2 Limitações ... 72
5.3 Trabalhos Futuros ... 72
5.3.1 Modelagem Visual de Agentes Inteligentes ... 72
5.3.2 Ferramenta Web de Gerenciamento de Componentes ... 74
5.4 Produção Científica ... 74
1 Introdução
Buscando a redução do impacto na adoção de Ambientes de Ensino a Distância (EAD), Ambientes Virtuais (AV) estão sendo aplicados, pois eliminam as fronteiras físicas para o aprendizado, de maneira que o desenvolvimento de habilidades cognitivas seja realizado com uso da Internet.
Nestes ambientes, a realidade pode ser descrita como ambientes interativos, compostos por objetos tridimensionais, com objetivo de simular ambientes reais ou imaginários, de maneira que os usuários interajam por meio da visualização e manipulação de objetos (Kirner e Siscoutto, 2007).
Nos últimos anos, AV tornaram-se uma das ferramentas adotadas para a composição de ambientes de aprendizagem em diversas áreas do conhecimento (Aquino et al., 2007), como por exemplo os relacionados às áreas de Medicina e Engenharia de Software.
Especificamente na área de medicina, pode-se citar como exemplo o MEDIDACTE Project (Soul et al., 2001), o qual dispõe de um ambiente adaptativo para o desenvolvimento de capacidades na referida área. Uma importante característica do projeto é a adaptatividade, que permite tratar de maneira individual as necessidades inerentes de cada usuário, considerando a sua capacidade cognitiva.
Por outro lado, na área de Engenharia de Software, existe um ambiente de ensino a distância chamado Project Management Knowledge (PMK) Learning Environment (Torreão, 2005), que atua no ensino de conceitos na área de Gerência de Projetos (GP). Atuando na mesma área, o Honey (Souza et al., 2008) possui foco no ensino de metodologias ágeis, em especial a metodologia Extreme Programming (XP) (Beck, 2000; Martin, 2003).
Apesar dessa evolução, as ferramentas que utilizam AV têm no processo de criação dos seus ambientes uma limitação. Uma vez que os artefatos são gerados pelas ferramentas ou frameworks estão limitados apenas à aquela plataforma. Entretanto, estes artefatos poderiam representar boas soluções na área e serem disseminados, ou ainda evoluídos em outras plataformas, o que é impossibilitado pela limitação supracitada.
Neste contexto, a introdução de técnicas de reuso poderia estimular a criação de AV melhores, independentemente de plataformas, visto que as boas soluções geradas pela comunidade poderiam ser reutilizadas e possivelmente aprimoradas.
O Reuso de Software comumente é relacionado a aumento de produtividade e qualidade nos artefatos gerados, que podem ser reutilizados em vários projetos. Segundo Souza e Wills (1999), nesta área quando se cita o Reuso de Software não apenas se refere ao código fonte, mas também às interfaces de usuário, testes, entre diversos artefatos relacionados.
Na área de Reuso de Software, existem diversas abordagens, entre elas o Desenvolvimento Baseado em Componentes (DBC) (Sametinger, 1997), Linguagens Específicas de Domínio, mais comumente conhecidas pela sua sigla DSL, referindo-se ao termo em inglês Domain Specific Languages (DSL) (Fowler, 2010; Mernik et al., 2005).
Além dos citados, existem técnicas como Reengenharia de Software (Jacobson e Lindstrom, 1991), Designação de Frameworks (Johnson, 1997), entre outras abordagens menos populares.
Entre as técnicas citadas anteriormente, o DBC tem destaque como uma abordagem promissora na área de Realidade Virtual (Oliveira et al., 2009), uma vez que componentes são reutilizáveis, intercambiáveis, de uso geral ou específicos, podendo interagir ainda com outros componentes.
1.1
Motivação
Com objetivo de usufruir dos benefícios da abordagem do DBC em ambientes de RV, pode-se criar um serviço de repositório de Ambientes Virtuais, possibilitando o armazenamento, busca e recuperação destes ambientes (Guo e Luqui, 2000), o que possibilita a contribuição para a disseminação das soluções.
Entretanto, verifica-se que, em alguns casos, tem-se a disponibilização de ambientes tridimensionais ou componentes de Software, porém, seguem a mesma limitação técnica, na qual os componentes estão destinados a apenas uma plataforma. Além disto, os repositórios não atuam de maneira distribuída, limitando a escalabilidade e disponibilidade do sistema.
1.2
Objetivos
Esta dissertação tem como objetivo principal propor, construir e validar um framework que fornece uma infraestrutura para disponibilização de componentes em RV, seja componente de Software, ou de ambientes tridimensionais, como qualquer artefato que possa ser descrito por meio desta infraestrutura.
A infraestrutura desenvolvida, denominada AvComponent framework disponibiliza estes componentes em um repositório baseado em Cloud Computing, que possibilita o compartilhamento dos componentes de maneira distribuída.
1.2.1 Objetivos Específicos
Analisar as técnicas de Reuso de Software e suas aplicações em Ambientes Virtuais;
Desenvolver um framework visando definir componentes na área de RV;
Analisar as técnicas de Cloud Computing, em especial Cloud Databases;
Desenvolver um repositório para os componentes integrado ao framework desenvolvido, disponibilizado em um ambiente de Cloud Computing; e
Validar o framework desenvolvido em integração com a ferramenta VEPersonal.
1.3
Organização do Trabalho
Além desta introdução, este trabalho está organizado em mais seis capítulos como se segue:
Capítulo 2 – Referencial Teórico: Nesse capítulo, serão abordados inicialmente
conceitos essenciais na área de Realidade Virtual (RV), Computação nas Nuvens (Cloud Computing - CC), com ênfase em Banco de Dados nas Nuvens (Cloud Databases). Além destes assuntos, ainda são abordados conceitos de Engenharia de Software, com foco
especial em DBC. Por fim, é realizada uma análise dos trabalhos relacionados e as considerações finais do capítulo.
Capítulo 3 - Uma Infraestrutura para Reutilização de Ambientes Virtuais Tridimensionais com Técnicas de Reuso de Software e Cloud Computing: Nesse
capítulo, será abordada a metodologia de desenvolvimento adotada para a construção do framework e os detalhes da sua arquitetura de software, incluindo as tecnologias utilizadas, e na sequencia descrevem-se os testes de software realizados.
Capítulo 4 - Aplicação do Framework para Reuso de Ambientes na Ferramenta VEPersonal: Nesse capítulo, é abordada a ferramenta VEPersonal, que será usada como
estudo de caso, detalhando todo o processo de integração. Na sequência, tem-se detalhes sobre a execução e avaliação do estudo de caso, seguido pelas considerações finais do capítulo.
Capítulo 5 – Conclusões e Trabalhos Futuros: Neste capítulo é realizada a
apresentação das contribuições do trabalho, seguida das suas limitações. Na sequência, serão apresentados alguns possíveis trabalhos futuros e a produção científica resultante deste trabalho.
2 Referencial Teórico
Esta dissertação envolveu três abrangentes linhas de pesquisa, que são a Realidade Virtual, Computação nas Nuvens e Engenharia de Software.
Com objetivo de esclarecer cada uma destas linhas de pesquisa, assim como os pontos relevantes para este trabalho, neste capítulo são descritos conceitos relacionados à Realidade Virtual, incluindo as formas de representação e armazenamento.
Em seguida, é examinada a computação das nuvens e, em especial, o banco de dados nas nuvens. Por fim, são tratados conceitos de engenharia de software importantes para este trabalho, como Reuso de Software e a sua técnica chamada desenvolvimento baseado em componentes.
2.1
Realidade Virtual
A área de RV é uma das subáreas da Computação Gráfica que permite a criação de ambientes gerados por computador que lidam com características como imersão, de maneira que a realidade é representada por meio de objetos tridimensionais (Machado, 2003; Kirner e Siscoutto, 2007).
Segundo Braga (2001), o termo RV se refere a uma técnica avançada de interface, que prevê a interação do usuário por meio de ambientes tridimensionais. Complementarmente, o mesmo autor explicita que a RV é composta de três ideias básicas: interação, envolvimento e imersão.
Os ambientes construídos com emprego de Realidade Virtual são também conhecidos por AV, e conforme Oliveira et al. (2009) pode ser definido como um ambiente na qual é incorporado algum avatar, ou seja, o usuário atua como um personagem, podendo interagir com o ambiente, o qual pode ser compostos por diversas entidades, a exemplo de casas, veículos ou pessoas (Singhal e Zyda, 1999).
Desta maneira, torna-se possível a participação e interação de diversos usuários entre si e em tempo real, de maneira que estes passam estar conectados em locais geograficamente diferentes, colaborando e interagindo entre si (Kirner e Siscoutto, 2007).
Em sistemas de RV, a interatividade está relacionada às respostas do sistema em função das ações do usuário, envolvendo navegação e capacidade de manipular objetos do mundo virtual (Pessin et al., 2008). Entretanto, para que esta interatividade seja desempenhada de maneira mais realista é essencial que a geração de imagens seja em tempo real e direcionada às necessidades do usuário.
Neste contexto, Braga (2001) também relaciona alguns benefícios na utilização de Realidade Virtual:
Amplia a motivação dos usuários;
Aprimora capacidade de representação de conceitos;
Permite a análise do ambiente em diversos âmbitos;
Possibilita a realização de novas experiências;
Possibilita conhecer o seu próprio nível de aprendizado; e
Facilita o manuseio de pessoas com deficiência de maneira a realizar tarefas antes não possíveis.
De acordo com o modo de interação do usuário, os AV podem ser classificados em:
Ambientes Imersivos: nestes ambientes, o usuário tem a sensação que as suas atividades produzem reações em ambientes virtuais. Para o desenvolvimento de ambientes imersivos, é necessária a aquisição de dispositivos que possibilitem a captura dos movimentos do usuário, como por exemplo, luvas e capacetes digitais (Kirner, 1996); e
Ambientes Não-Imersivos: nestes ambientes, as interações com os ambientes tridimensionais serão realizadas com emprego de monitores de vídeo. Embora estes não necessitem de dispositivos de captura de movimentos, muitas vezes são os mais adotados, pois possuem menor custo envolvido, são independentes da localização geográfica do usuário, e, além disso, podem fazer uso das novas tecnologias para representação de ambientes tridimensionais existentes (Kirner, 1996).
Devido à inserção de ambientes tridimensionais que representam à realidade, assim como a associação de atributos como interação, envolvimento e imersão, os ambientes virtuais são frequentemente aplicados em sistemas de entretenimento e educação (Braga, 2014).
No entanto, a aplicabilidade destes ambientes não se restringe aos citados anteriormente, podendo ser utilizados em sistemas de simulação, como por exemplo, o Second Life, mostrado na Figura 1, que conforme o nome se propõe, disponibiliza um ambiente tridimensional de maneira que você pode escolher o seu avatar, podendo interagir com outras pessoas, representando uma segunda vida, porém dentro deste ambiente.
Figura 1: Apresentação do Jogo Second Life
Fonte: http://www.secondlife.com
No sentido de ampliar a discussão sobre o assunto, a Seção 2.1.1 apresenta as formas de representação de objetos tridimensionais geralmente empregadas para o desenvolvimento de ambientes virtuais, enquanto na Seção 2.1.2 serão discutidas as formas de armazenagem destes ambientes.
2.1.1 Representação de Objetos Tridimensionais
Para o desenvolvimento de Ambientes Virtuais, tem-se a necessidade de utilização de uma linguagem que possibilite a definição de objetos tridimensionais, podendo descrever propriedades como cor, escala, dimensões, posicionamento e forma, de maneira que o usuário possa interagir e recuperar informações (Aquino et al., 2007).
Atuando neste sentido, com relação a linguagens utilizadas para representação dos objetos tridimensionais, será relacionado neste trabalho o Java 3D (Sowizral et al., 1997), Virtual Reality Model Language (VRML) (Ames et al., 1997) e Extensible 3d (X3D) (X3D, 2014).
O framework Java3D é escrito com a linguagem Java (Java, 2014), e possui um conjunto de classes que abstraem a complexidade na criação e manipulação de objetos geométricos, com objetivo de fornecer um framework que atue independentemente de plataforma, assim como é a linguagem Java e o VRML, que são discutidos na sequência (Barrilleaux, 2000).
Conforme se pode verificar na Figura 2 abaixo, as aplicações que usam o framework Java 3D estão escritas em um nível mais alto de abstração, ocultando detalhes na geração de gráficos, informações de hardware, entre outras informações.
Figura 2: Camadas de Software do framework Java 3D
Na sequência, é abordada a linguagem VRML. Esta permite a construção de mundos virtuais com objetos persistidos no sistema de arquivos, devendo ao ambiente possuir todas as características necessárias para sua execução (Carey e Bell, 1997).
Por fim, a linguagem X3D, provida pela Web3D Consortium, é uma evolução do VRML supracitado, caracterizado por uma padronização mais elaborada, que permite a manipulação de objetos em tempo real, desta maneira promovendo o reuso, além de ter integração com Serviços Web, o que dá a possibilidade de vincular recursos externos, além de permitir a integração entre sistemas (Brutzman, 2010).
Após apresentação de como os ambientes tridimensionais podem ser representados, na Seção 2.1.2 apresenta como estes são armazenados.
2.1.2 Armazenamento de Objetos Tridimensionais
As linguagens como a X3D permitem construir ambientes tridimensionais utilizando uma estrutura XML, atuando especificamente nesta linguagem, uma vez que este trabalho faz uso desta linguagem, nesta seção são identificadas as maneiras com que estes objetos tridimensionais que compõem estes ambientes podem ser armazenados visando a identificação de maneiras de promover a reutilização destes.
a) Banco de Dados Relacional
A origem do termo Banco de Dados (BD) surge da palavra em inglês databank, de maneira que os primeiros trabalhos usaram este termo. Porém, o termo passou a ser descontinuado, enquanto o termo database, que significa Base de Dados passou a ser usado amplamente até os dias atuais (Heuser, 2011).
O modelo de BD Relacional foi introduzido pelo pesquisador inglês Edward Frank Codd (1970) no artigo A relational model for large shared data banks, na qual se baseia na teoria das relações para fornecer o gerenciamento de dados.
O termo BD se refere ao mecanismo de armazenamento e recuperação de dados, de forma que o que torna relacional é o modo com que estes dados estão dispostos, em que neste caso, refere-se às tabelas, na qual os relacionamentos entre tabelas as tornam relacionais e atualmente é o tipo mais amplamente usado nos sistemas (Heuser, 2011).
Pode-se citar como exemplos de Sistemas de Gerenciamento de Banco de Dados (SGBD) relacionais amplamente usados o MySQL (MySQL, 2014), PostgresSQL (PostgreSQL, 2014), SQL Server (SQLServer, 2014) e o Oracle Database (Oracle, 2014).
O uso deste tipo de SGBD em aplicações de RV acontece por meio da utilização de campos para armazenamento de texto, na qual são inseridos os arquivos X3D em formato XML, ou ainda, em formato binário (Aquino et al., 2007), entretanto ambas as abordagens hoje não são amplamente usadas devido às funcionalidades de manipulação de arquivos em formato XML descritas a seguir.
b) Banco de Dados (XML nativo ou com suporte para XML)
Para permitir um tratamento de documentos XML de maneira mais eficiente, surgiram os SGBD XML, que nativamente possuem modelo lógico baseado em documentos XML (Mello, 2002).
Os SGBD XML, visando interagir com o XML persistido incorporam linguagens de consultas como o XPath (XPath, 2014) ou o XQuery (XQuery, 2014), que possibilitam consultar padrões em textos ou consultar por trechos do arquivo XML, obtendo como resposta fragmentos do arquivo ou ainda informações em específico.
Neste contexto, tem-se SGBD que foram desenvolvidos especificamente para trabalhar com documentos XML, que são os SGBD XML nativos, a exemplo do Oracle Berkeley DB (Olson et al., 1999). Por outro lado, existem outros tipos de SGBD que podem adquirir tais funcionalidades com uso de extensões como é o caso do PostgreSQL (Kido et al., 2006).
O uso deste tipo de SGBD em aplicações de RV acontece por meio da utilização de consultas em formato XML persistidas, podendo retornar trechos do ambiente, ou ainda informações específicas, entretanto com um desempenho superior aos de SGBD relacionais, visto que o tratamento do arquivo XML é realizado pelo SGBD, seja de maneira nativa ou customizada com uso de bibliotecas (Sousa et al, 2010).
c) Banco de Dados Nas Nuvens
A Cloud Computing surge como uma possibilidade de expor suas aplicações, e neste caso o SGBD, em um ambiente de terceiros, que dispõe de toda a infraestrutura necessária (Abadi, 2009).
Por se tratar de um tema emergente, o qual o framework proposto neste trabalho abordará, as Seções 2.2 e 2.3 tratam respectivamente dos temas Computação das Nuvens (Cloud Computing) e Banco de Dados nas Nuvens (Cloud Databases).
2.2
Computação nas Nuvens (Cloud Computing)
O termo cloud se originou na área das telecomunicações, ao utilizarem os serviços de Virtual Private Network (VPN) para comunicação de dados (Jadeja e Modi, 2012). Posteriormente, este termo migrou para a área de Tecnologia da Informação (TI), movendo computação e dados para Data Centers.
A definição de Cloud Computing mais disseminada foi provida pelo National Institute of Standards and Technology (NIST) informa que “Computação em Nuvem é um modelo que possibilita acesso, de modo conveniente e sob demanda, a um conjunto de recursos computacionais configuráveis que podem ser rapidamente adquiridos e liberados com mínimo esforço gerencial ou interação com o provedor de serviços” (Mell e Grance, 2011; Jansen e Grande, 2011).
Na seqüência é mostrada na Figura 3, segundo a definição do NIST, quais seriam as características essenciais, modelos de serviço e implantação, que serão aprofundadas em seções posteriores.
Figura 3: Relação das Características Essenciais, Modelos de Serviço e Modelos de Implantação
Fonte: Adaptado de Mell e Grance (2011)
Segundo Jadeja e Modi (2012), o principal objetivo da Cloud Computing é fazer melhor uso de recursos distribuídos, combinando-os para obter maior rendimento e ser capaz de solucionar problemas de escalabilidade em computação.
Armbrust et al. (2012), em seu trabalho A View of Cloud Computing, define Cloud Computing e se refere à aplicações entregues como serviços na Internet e Hardware e Software alocados em Data Centers, que provêem estes serviços.
Nos últimos anos, o conceito de Cloud Computing se difundiu, de maneira que o pagamento é realizado da mesma maneira de uma conta de água, luz ou telefone, isto é, baseado no uso (Weinhardt, 2009). Desta maneira, a utilização de recursos de computação passam a ser disponilizados de maneira transparente com pagamento baseado na utilização.
Armbrust et al. (2012) sintetiza no Quadro 1 abaixo os dez obstáculos para o crescimento deste tema e, para cada um dos obstáculos, as oportunidades existentes. Conforme o mesmo autor, os três primeiros afetam a adoção, os próximos cinco afetam o crescimento e os dois últimos são políticas e obstáculos no negócio.
Quadro 1: Obstáculos e Oportunidades em Cloud Computing
Fonte: Lima (2014)
Nas próximas seções, descrevem-se em maiores detalhes as características essenciais da Computação nas Nuvens, modelos de serviço e modelos de implantação, até que na sequencia discutiremos o tema Cloud Databases.
2.2.1 Características Essenciais
Conforme discutido anteriormente, a definição de Cloud Computing proposta pelo NIST, sintetizada na Figura 3, elencava algumas de suas características, relacionada na Figura 4 a seguir e discutida em maiores detalhes na sequência.
Figura 4: Características Essenciais de Cloud Computing
Fonte: Adaptado de
http://engineeringmentor.com/cloud-computing-characteristics-the-essential-five-to-understand/
a) Auto-atendimento sob demanda (On-demand Self-service)
Neste caso, o cliente poderá adquirir recursos computacionais unilateralmente, na medida em que for necessário, sem interação humana. Por exemplo, o cliente possui um servidor nas nuvens de uma empresa e caso o tráfego esteja excedendo a quantidade adquirida, ou o processador ou espaço em disco estiver insuficiente, ou quaisquer outros recursos computacionais na mesma situação, pode-se adquirir mais recursos instantaneamente (Mell e Grance, 2011; Jansen e Grande, 2011; Sousa et al., 2010).
b) Rápida Elasticidade (Rapid Elasticity)
Neste caso, os recursos podem ser adquiridos e removidos com elasticidade, possibilitando escalabilidade de acordo com a demanda e a possibilidade de liberação de recursos quando há uma diminuição da demanda, ou seja, de acordo com o ponto de vista do usuário, os recursos parecem ilimitados (Mell e Grance, 2011; Sousa et al., 2010).
Usando o exemplo descrito anteriormente, em que o cliente tinha necessidade de mais recursos (seja de armazenamento, processamento, tráfego, entre outros), o fator descrito aqui (Rápida Elasticidade) possibilita que os recursos solicitados estejam disponíveis instantaneamente (Sousa et al., 2010).
c) Amplo Acesso à Rede (Ubiquitous Network Access)
Neste caso, os serviços disponibilizados na nuvem estão acessíveis de qualquer plataforma, sendo usadas em plataformas heterogêneas, por exemplo, para um computador pessoal ou um smartphone (Mell e Grance, 2011; Sousa et al., 2010).
d) Pool de Recursos (Resource Pooling)
Neste caso, os recursos computacionais são organizados em um pool para servir múltiplos usuários, ou seja, há uma virtualização de armazenamento de maneira que a localização física dos recursos é transparente para o usuário (Mell e Grance, 2011; Sousa et al., 2010).
e) Serviços Mensuráveis (Measured Service)
Neste caso, os recursos adquiridos são controlados e monitorados automaticamente, de maneira que há uma transparência entre o cliente e o fornecedor, informando os serviços adquiridos e a utilização em dado momento (Mell e Grance, 2011; Sousa et al., 2010).
Além da transparência, permite ao cliente evitar a indisponibilidade do serviço por algum recurso computacional, de maneira que, em dado momento recursos complementares podem ser adquiridos para suprir uma possível falta.
Após apresentação dos detalhes dos itens elencados pelo Nist (Mell e Grance, 2011; Jansen e Grande, 2011) como características essenciais da Computação nas Nuvens, na Seção 2.2.2 serão detalhados os modelos de serviço
2.2.2 Modelos de Serviço
Seguindo a definição de Cloud Computing proposta pelo Nist, sintetizada na Figura 3, foram elencados três tipos de modelos de serviço, detalhados posteriormente e relacionados na Figura 5.
Figura 5: Modelos de Serviço
Fonte: Adaptado de http://www.cloudreview.in
a) Software as a Service (SaaS)
Dentre os três modelos de serviço, o SaaS é o mais amplamente conhecido, visto que o foco principal são os usuários finais, conforme relacionado na Figura 5, fornecendo os serviços de uma aplicação sendo executada na infraestrutura nas nuvens.
Pode-se citar como exemplos, o Google Drive e o Amazon S3, que oferecem serviços de armazenamento de dados nas nuvens (Cloud Storage), assim como o Gmail, que atua provendo serviços de correio eletrônico. Ainda podem-se citar como exemplos, os aplicativos apresentados na Figura 6.
Nota-se que muitas destas aplicações são amplamente utilizadas e os usuários desconhecem a infraestrutura subjacente que provê o serviço.
Figura 6: Exemplo de Aplicativos no Modelo Software as a Service (SaaS)
Fonte: Adaptado de http://www.cloudreview.in
b) Platform as a Service (PaaS)
Provê ao consumidor a capacidade de implantar aplicações criadas pelo próprio usuário ou desenvolvidas pelo provedor em uma infraestrutura na Cloud Computing (Mell e Grance, 2011). Por este motivo, conforme relacionado na Figura 5, o foco principal são os desenvolvedores.
Pode-se citar como exemplos, os aplicativos apresentados na Figura 7, entre os quais se pode destacar o Windows Azure, no qual qualquer desenvolvedor cadastrado pode enviar os seus aplicativos e a infraestrutura é controlada pela Microsoft.
Figura 7: Exemplo de Ambientes no Modelo Platform as a Service (PaaS)
Complementarmente, Sousa et al (2010) informam que um PaaS fornece sistema operacional, linguagens de programação e ambiente de desenvolvimento para aplicações, auxiliando a implementação de sistemas de software.
c) Infrastructure as a Service (IaaS)
Neste caso se tem acesso transparente aos servidores, as redes e ao armazenamento ou outros recursos computacionais, podendo desta forma executar qualquer software, incluindo sistemas operacionais (Mell e Grance, 2011).
Seguindo a mesma ideia dos anteriores, a infraestrutura é controlada e monitorada pelo provedor, como é o exemplo do Amazon Elastic Cloud Computing (EC2), que provê acesso a máquinas virtuais hospedadas no Data Center da Amazon (Sousa et al., 2010).
Com a designação do modelo de serviço é necessário selecionar o modelo de implantação, que conforme se discute na Seção 2.2.3, depende principalmente da necessidade, assim como do objetivo do negócio a ser implantado.
2.2.3 Modelos de Implantação
Após selecionar o modelo de serviço, que pode ser IaaS, PaaS ou SaaS, há a necessidade de definir qual o modelo de implantação necessária, uma vez que tem-se a necessidade de ambientes mais restritos, pois dependendo da área de negócio, a exposição dos dados nas nuvens pode se tornar uma vulnerabilidade.
De acordo com Sousa et al. (2010), a escolha do modelo de implantação está baseada nos seguintes itens:
Restrição ou Abertura de Acesso;
Área de Atuação;
Tipo de Informação; e
Neste contexto, os Modelos de Implantação segundo a definição de Cloud Computing proposta pelo Nist, são detalhados posteriormente e relacionados na Figura 8.
Figura 8: Relacionamento entre os Modelos de Implantação
Fonte: Sousa et al. (2010)
a) Nuvem Pública
A infraestrutura da Cloud é provisionada para uso geral e amplamente disponível e está sob as premissas do provedor da Cloud, fazendo com que tenha perspectiva de redução na sua utilização, devido a segurança dos dados, o que impulsionou a Nuvem Híbrida, que é detalhada na sequência (Sousa et al., 2010).
b) Nuvem Privada
A infraestrutura da Cloud é provisionada para uso exclusivo para apenas uma organização (Sousa et al., 2010).
c) Nuvem Comunidade
A infraestrutura da Cloud é provisionada para uso exclusivo por uma comunidade de consumidores de organizações que possuem interesses comuns, a exemplo de requisitos de segurança, política, entre outros requisitos (Sousa et al., 2010).
d) Nuvem Híbrida
A infraestrutura da Cloud é a composição de dois ou mais distintas infraestruturas nas nuvens (privada, pública ou comunidade), de forma que permanecem entidades únicas, ou seja, virtualizadas como uma única entidade, porém unidas por tecnologia, permitindo, por exemplo, balanceamento de carga entre nuvens (Sousa et al., 2010).
2.2.4 Tendências da Cloud Computing
De acordo com Morrissey (2014), o tema Cloud Computing seguirá transformando a maneira como as organizações fazem negócios e pode-se esperar um aprimoramento nos mecanismos de segurança e controle corporativo, de maneira que as empresas possam mover processos importantes para a nuvem.
Skok (2014) assinalou que a Nuvem Híbrida passará a ser a mais utilizada nos próximos 5 anos, enquanto que a Nuvem Pública diminuirá substancialmente devido a preocupações com segurança.
Com apresentação das características essenciais da Computação nas Nuvens, seus modelos de serviço e implantação, na Seção 2.3 será detalhado uma tendência de aplicações em Cloud Computing, que é o Banco de Dados nas Nuvens (Cloud Databases).
2.3
Banco de Dados nas Nuvens (Cloud Databases)
Nos últimos anos, com o crescimento de ferramentas baseadas na Cloud Computing, surge a possibilidade de disponibilizar banco de dados, como uma opção para redução de custo através do medição da utilização dos serviços, disponibilizando a infraestrutura e o sistema para terceiros (Abadi, 2009).
Outro fato que torna o banco de dados candidatos potenciais para implantação na nuvem é a manutenção de um banco de dados em sua infraestrutura temos uma instalação complexa e o alto custo de hardware, assim como licenciamento (Sousa et al., 2010).
Em seu artigo Relational Cloud: The Case for Database Service, Curino et al. (2010), após discussão com pesquisadores na área e potenciais usuários, elencou quais
seriam os requisitos chave para um SGBD atuar como um serviço, apresentado no Quadro 2. Desta forma, os clientes podem ter maior previsibilidade, custos inferiores e redução de complexidade técnica (Curino et al., 2010).
Quadro 2: Requisitos chave para um SGBD nas nuvens
Fonte: Sousa et al. (2010)
Baseado nos requisitos expostos anteriormente, Sousa et al. (2010) apresentaram como seria uma estrutura básica de um Banco de Dados atuando como Serviço, mostrada na Figura 9. Cada inquilino contrata o provedor de serviços e a responsabilidade de disponibilidade e confiabilidade são transferidos ao provedor, mantendo a transparência da infraestrutura ao usuário .
Figura 9: Estrutura Básica de um Banco de dados como Serviço
Fonte: Sousa et al. (2010)
Após apresentar a estrutura básica de um Banco de Dados como Serviço, na Seção 2.3.1 apresentam-se as categorias de Banco de Dados na Cloud Computing.
2.3.1 Categorias
O Banco de Dados na Cloud Computing, conforme apresentado na Figura 10, podem ser classificados em Relacionais e Não-Relacionais, estes últimos podendo ser considerados como Nativos ou Não-Nativos, de forma que:
No primeiro quadrante, tem-se SGBD relacionais construídos para operar nas nuvens, incluindo funcionalidades de administração de dados adequadas;
No segundo quadrante, tem-se SGBD que não foram concebidos para a nuvem, entretanto podem ser utilizados neste sentido;
No terceiro quadrante, tem-se SGBD que foram concebidos para a nuvem e não são relacionais, utilizando o par chave-valor, tendo-se como exemplos o Amazon S3, HBase, Cassandra e o Voldermont.
No quarto e último quadrante, tem-se SGBD que não são relacionais e não foram concebidos para as nuvens, como é o caso do Neo4j, Orient DB, Couch DB e o Mongo DB.
Figura 10: Classificação de Banco de Dados nas Nuvens
Fonte: Adaptado de Sousa et al. (2010)
Na Seção 2.4 descreve-se a Engenharia de Software, destacando técnicas de Reuso de Software e uma das suas principais técnicas que é o Desenvolvimento Baseado em Componentes.
2.4
Engenharia de Software
Engenharia de Software (ES) é o estabelecimento e o emprego de sólidos princípios de engenharia para obtenção de software de forma econômica, que seja confiável e eficiente em máquinas reais (Mahoney, 2004).
Em outra visão, Musa (1975), define ES como a aplicação da abordagem sistemática, disciplinada e quantificável no desenvolvimento, na operação e na manutenção do Software.
Em 1968, diante da crise do software, em uma conferência na Organização do Tratado do Atlântico Norte (OTAN), Mc Ilroy, conforme mostrado na Figura 11 apresenta as primeiras ideias e os benefícios referentes ao conceito que existe de reuso de software.
Figura 11: Disseminação das primeiras ideias sobre reuso de software
Fonte: http://homepages.cs.ncl.ac.uk/brian.randell/NATO/N1968
Complementarmente, Krueger (1992) relata que durante esta conferência foi apresentada uma definição simples, porém poderosa de reuso de software, momento em que, segundo sua opinião, deveria ter se tornado um padrão em Engenharia de Software.
2.4.1 Reuso de Software
Entre as técnicas de programação, o Reuso de Software é uma das menos evidenciadas, pela sua complexidade e ao baixo conhecimento do corpo técnico a respeito do assunto. Com a utilização desta técnica, para um código desenvolvido, testado e disponibilizado em ambiente de produção, este poderia ser reutilizado em outros cenários similares.
No ano de 1992, Charles Krueger relatou um cenário em que as empresas buscavam melhorias em seu processo de criação de software, principalmente no que diz respeito a
qualidade e produtividade. Neste contexto, Krueger (1992) define Reuso de Software como o processo de criar novos aplicativos a partir de já existentes ao invés de construí-los desde o início.
O reuso de software possibilita, de acordo com Freeman (1987), o uso destes artefatos em outro cenário para o qual não foi produzido inicialmente. Em visão complementar, Werner e Braga (2000), relatam que o reuso necessita de uma sistemática ampla e formal para realizá-la, podendo obter os benefícios e dificuldades descritos no Quadro 3.
Quadro 3: Benefícios e Dificuldades na Abordagem de Reuso de Software Benefícios - Qualidade - Produtividade - Redução de Custos - Redução de Tempo - Flexibilidade Dificuldades
- Identificação, recuperação, compreensão
- Modificação, composição
- Qualidade de componentes
- Barreiras psicológicas, legais e econômicas
- Necessidade de incentivos
Para determinar boas propriedades para reuso de software, Krueger (1992) define cinco dimensões:
Abstração - Identificar unidades de conhecimento reutilizáveis e representá-los de forma abstrata;
Classificação - Armazenar o conhecimento reutilizável em uma base de conhecimento classificada e indexada;
Seleção - Consultar o conhecimento reutilizável em forma parametrizada;
Especialização - Modificar o conhecimento reutilizável para atender novas situações; e
Integração - Combinar o conhecimento reutilizável com seu projeto.
Pode-se citar como exemplos clássicos de reuso de software: as linguagens de programação de alto nível, como a linguagem Java (Gosling, 2000), frameworks, como o Swing (Ekstein et al., 1998) que atua na construção de interfaces gráficas.
Nesta área, existem diversas abordagens, entre elas o DBC (Sametinger, 1997), Linguagens Específicas de Domínio, mais comumente conhecidas pela sua sigla DLS, referindo-se ao termo em inglês Domain Specific Languages (DSL) (Fowler, 2010).
Além das abordagens citadas, existem técnicas como Reengenharia de Software (Jacobson e Lindström, 1991), frameworks de aplicação (Camargo e Masiero, 2005), padrões de projeto (Gamma et al., 1994), desenvolvimento de software orientado a aspectos (Elrad e Bader, 2001), entre outras abordagens menos populares.
Na Seção 2.4.1.1 serão detalhados os conceitos de DBC, que possui abordagens bem sucedidas em integração com aplicações na área de RV (Oliveira et al, 2009), uma vez que componentes são reutilizáveis, intercambiáveis, de uso geral ou específicos, podendo interagir ainda com outros componentes.
2.4.1.1 Desenvolvimento Baseado em Componentes
Segundo Werner e Braga (2000), componentes de software são artefatos autocontidos, identificáveis, possuindo função específica com interfaces bem definidas, de forma a propiciar a sua reutilização em outros ambientes.
Uma visão complementar, Singhal e Zyda (1999) definem componentes como uma unidade que possui interfaces especificadas previamente definidas, por meio de contratos e dependências de contexto explícitas.
Nesta abordagem, um aplicativo é criado a partir da integração entre diversos componentes, fazendo com que, após serem desenvolvidos possam ser reutilizados integralmente em outros aplicativos, viabilizando o aumento de produtividade (Sommerville, 2003).
Morisio (2000) relata que é necessária a introdução de processos de software específicos ao invés de adaptar os processos tradicionais ao paradigma DBC, que é uma das principais causas para fracasso na adoção do DBC. Complementarmente, Sommerville (2003) propõe um fluxo de atividades para o processo de desenvolvimento de sistemas baseados no paradigma DBC, mostrado na Figura 12.
Figura 12: Processo de Desenvolvimento de software baseado em DBC proposto por Sommerville
Segundo Henninger (1997), um ponto chave para obtenção de melhores resultados com DBC é a estruturação de um repositório para acesso e disponibilização dos componentes.
Para a estruturação de um repositório, Guo e Luqui (2000) elencaram no Quadro 4 os requisitos para estruturação de um repositório de componentes, que conforme Werner e Braga (2000) podem ser classificados em: locais, específicos a um domínio e de referência.
Quadro 4: Requisitos para Estruturação de um Repositório de Componentes
Interface para as operações básicas no manuseio de componentes (uso, pesquisa e disponibilização).
Disponibilização de documentação sobre cada componente.
Estrutura padrão para os componentes.
Esquema para classificação nos mais diversos domínios.
Fonte: Guo e Luqui, 2000
Compartilhando a mesma visão, Werner e Braga (2000) identificam que a chance de um desenvolvedor reutilizar um dado componente está diretamente relacionada a disponibilidade com que um componente possa ser localizado e recuperado.
Na Seção 2.5 serão relacionadas as ferramentas que trabalham com aplicação de DBC na área de RV, que é o foco deste trabalho, considerando ambientes nas nuvens, assim como ambientes que não estão nas nuvens.
2.5
Trabalhos Relacionados
O levantamento bibliográfico realizado teve como principal objetivo identificar os sistemas que possuem suporte ao desenvolvimento de aplicações envolvendo conceitos de RV, DBC e Cloud Computing.
Neste contexto, para descrever os trabalhos relacionados, foram definidos critérios de inclusão e exclusão, que foram:
- Critérios de Inclusão:
Plataformas/Aplicações/Frameworks que possuem suporte ao desenvolvimento de aplicações na área de RV;
Plataformas/Aplicações/Frameworks que possuem suporte ao desenvolvimento de aplicações na área de RV com base no DBC; e
Plataformas/Aplicações/Frameworks que possuem suporte ao desenvolvimento de aplicações na área de RV com infraestrutura nas Nuvens.
- Critério de Exclusão:
Plataformas/Aplicações/Frameworks que não possuem suporte ao desenvolvimento de aplicações na área de RV.
2.5.1 NRVA
.
Relacionando o conceito de DBC na área de RV e RA em um ambiente na nuvem, o NRVA (Freiberger, 2013) apresenta um modelo arquitetural de uma plataforma de produção, compartilhamento e execução de aplicações de realidade virtual e aumentada, apresentado na Figura 13.
A plataforma NRVA conta com dois níveis de abstração, o módulo Serviços de Plataforma, que são os serviços básicos ofertados aos clientes, enquanto que o módulo Subsistemas de Plataforma concentra os serviços de baixo nível, como controle de acesso e recursos, produção, execução e renderização de mundos 3D (Freiberger, 2013).
Figura 13: Arquitetura do NRVA
Fonte: Freiberger (2013)
2.5.2 Java Adaptive Dynamic Environment .
Em uma perspectiva diferente do NRVA, o Java Adaptive Dynamic Environment (Oliveira et al., 2003) disponibiliza um framework para o desenvolvimento de aplicações de RV na linguagem Java (Goesling, 2000), de forma a unificar e padronizar este processo. Entretanto, não há uma clara definição dos componentes, assim como estes poderiam ser reutilizados em outras plataformas.
2.5.3 Transformer Substation Simulation (TSS)
A ferramenta TSS (Li et al., 2010) possui similaridades com o NRVA, para criar uma infraestrutura para desenvolvimento de aplicações de RV, de forma que nesta aplicação é definido um ambiente de simulação de transformação em estações de energia elétrica, como os apresentados na Figura 14.
Também é evidenciada neste trabalho a redução de custo, assim como aumento na qualidade de software, uma vez que todos os componentes são gerados e montados por meio da ferramenta.
Figura 14: Ambiente do TSS
Fonte: Li et al. (2010)
2.5.4 Virtual Medical Training (ViMeT)
Com atuação na produção de aplicações para simulação de exames de biópsia, como os da Figura 15, o Virtual Medical Training (ViMeT) possui grandes contribuições para a área, possibilitando a criação de ambientes amparados por uma metodologia, de forma que os ambientes criados de forma customizada podem ser reutilizados dentro da infraestrutura criada (Nunes, 2010).
Figura 15: Ambiente do ViMeT
Fonte: Nunes (2010)
2.6
Conclusões
Neste capítulo, foram apresentados conceitos fundamentais sobre RV, como a representação de objetos tridimensionais, além das formas de armazenamento, entre os quais o Banco de Dados nas Nuvens se destaca, devido as suas características de escalabilidade e disponibilidade, que em aplicações na área de RV são um diferencial.
Neste capítulo foram tratados ao leitor os conceitos fundamentais sobre Engenharia de Software, em especial o tema de Reuso de Software com a abordagem de DBC, que com a correta aplicação, possibilita o compartilhamento de soluções para aplicações futuras.
Sobre os trabalhos relacionados (Seção 2.5), foram apresentados quatro trabalhos que conforme os critérios apresentados estão sintetizados no Quadro 5. Verificou-se que o trabalho mais recente, o NRVA (Freiberger, 2013), reúne a maior parte das abordagens estabelecidas em nossos critérios, em comparação aos outros sistemas elencados.
Quadro 5: Comparativo entre as Ferramentas Analisadas Realidade Virtual Realidade Aumentada Infraestrutura nas Nuvens Desenvolvimento Baseado em Componentes
NRVA (Freiberger, 2013) Sim Sim Não Sim
Java Adaptive Dynamic Environment (Oliveira et al., 2003)
Sim Não Não Não
TSS (Li et al., 2010) Sim Não Não Sim
ViMeT (Nunes, 2010) Sim Não Não Não
Fonte: O Autor
Aliando aplicações na área de RV em um de Banco de Dados nas Nuvens, com estrutura de reuso de componentes desenvolvidos, no próximo capítulo será descrito o framework proposto neste trabalho.
3 AvComponent: Um Framework para Desenvolvimento
de
Componentes
de
Realidade
Virtual
em
Infraestrutura de Compartilhamento de Componentes
em Nuvem
Em decorrência do avanço da RV e dos recursos computacionais relacionados, AV com cenários de RV mais realistas podem ser desenvolvidos. Entretanto, durante o processo de criação destes ambientes, muitas vezes existe a limitação das soluções desenvolvidas para a plataforma em que foi concebida, inviabilizando o compartilhamento de artefatos que poderiam ser utilizados, ou ainda possivelmente aprimorados, em outras plataformas.
De forma a contribuir para solucionar esta limitação, é apresentado neste capítulo detalhes de um framework intitulado AvComponent, que busca promover o reuso de componentes de RV, que podem ser componentes de Software ou de ambientes tridimensionais.
Basicamente, este framework cria uma estrutura para definição de componentes na qual podem-se ser disponibilizados pelo repositório em uma infraestrutura de banco de dados nas nuvens. Desta forma, os usuários podem obter componentes de terceiros, assim como compartilhar os seus componentes.
Este capítulo está organizado da seguinte forma. A Seção 3.1 apresenta a metodologia adotada para o desenvolvimento da aplicação. Na Seção 3.2 são apresentados detalhes sobre a arquitetura da ferramenta, enquanto na Seção 3.3, é descrito como foi realizada a fase de testes durante o desenvolvimento da ferramenta. Por fim, a Seção 3.4 aborda as considerações finais.
3.1
Metodologia de Desenvolvimento
A adoção de uma metodologia é fundamental para guiar o processo de desenvolvimento de software, permitindo não somente definir quais etapas serão realizados no projeto, assim como controlar todas as atividades, pessoal e artefatos gerados durante a construção do sistema de software.
Neste sentido, a metodologia de desenvolvimento utilizada para a criação desta ferramenta foi a Scrum (Rubin, 2012), que é um processo de desenvolvimento ágil baseado em ciclos de aproximadamente trinta dias, conhecidos por Sprints.
Este processo relaciona três papéis (roles): Equipe (Team), Product Owner e o Scrum Master (Sutherland et al., 2007), cujas responsabilidades são apresentadas no Quadro 6.
Quadro 6: Relação dos Papéis e Responsabilidades no Processo Scrum
Role (Papel) Responsabilidade
Equipe (Team) Disponibilizar as soluções.
Product Owner Assegurar se a Team está desenvolvendo o
solicitado. Geralmente, isto é realizado pelo cliente ou alguém que possua a perspectiva do negócio.
Scrum Master Assegurar que as práticas do Scrum estão
realmente sendo executadas
Fonte: Sutherland et al. (2007)
Para o alcançe desta metodologia, são definidas as etapas apresentadas na Figura 16. Inicialmente o Product Owner indica quais as funcionalidades desejadas por meio do Product Backlog, que é um documento que descreve todos os objetivos daquele Sprint.
Posteriormente, as funcionalidades que serão implementadas no Sprint, tornam-se o chamado Sprint Backlog, que reflete as necessidades do cliente naquele Sprint.
Por fim, este Sprint Backlog deve ser implementado pela Equipe (Team) dentro de um Sprint, que possui variante de duas a quatro semanas. Durante este período, o Scrum Master fará reuniões diárias (chamadas de Daily Scrum Meeting) sempre no mesmo horário com a equipe, visando o conhecimento do andamento do projeto, assim como as necessidades envolvidas e as atividades planejadas.
Além disto, o papel Scrum Master também supervisionará as atividades para assegurar se as práticas deste processo estão sendo colocadas em sequência.
Figura 16: Representação do Processo de Desenvolvimento Scrum
Fonte: Adaptado de Rubin (2012)
A metodologia de desenvolvimento descrita anteriormente, utilizado para o desenvolvimento do framework apresentado, foi usada devido a sua objetividade, com a associação de apenas três papéis e a imposição de boas práticas no desenvolvimento (Rubin, 2012).
Após a apresentação da metodologia de desenvolvimento usada para a definição deste framework, na próxima seção inicia-se o detalhamento técnico sobre a arquitetura de software para construção do AvComponent.
3.2 Arquitetura de Software
O termo Arquitetura de Software, conforme Garlan e Perry (1994), é a estrutura de componentes do programa/sistema, suas inter-relações, princípios e diretrizes que regem sua concepção e evolução ao longo do tempo. Complementarmente, Bass (2007) define Arquitetura de Software como a(s) estrutura(s) do sistema, que são compostos por componentes de software, as interfaces destes componentes e suas respectivas relações.
Em uma visão mais recente, Barbosa (2009) descreve Arquitetura de Software como a organização do sistema, por meio de seus componentes, considerando os princípios de design e evolução.
A arquitetura do framework é apresentada na Figura 17, e está organizada em dois módulos, que são o módulo cliente e o módulo servidor, estruturados de maneira que os componentes sejam reutilizados, seguindo a técnica de reuso de software DBC.
Figura 17: Arquitetura do AvComponent
O primeiro módulo é o cliente, que representa a diversidade de sistemas que podem usufruir dos componentes de RV providos pelo servidor, usando este framework. Por outro lado, os componentes que são consumidos pelos clientes são gerenciados pelo módulo servidor, que possui o serviço Service Locator (SL), que verifica se o componente de RV requisitado está na infraestrutura de banco de dados nas nuvens.
Após a apresentação da arquitetura de software, na Seção 3.2.1 serão detalhadas as tecnologias envolvidas, enquanto os módulos que compõem a arquitetura são detalhados nas Seções 3.2.2 e 3.2.3.
3.2.1 Tecnologias
Para construção do framework AvComponent, a relação das ferramentas e frameworks estão descritas na Figura 18.
Figura 18: Relação das Tecnologias e Frameworks envolvidos no Desenvolvimento
No módulo cliente (browser), foi aplicado o toolkit Xj3d, que permite a importação de ambientes escritos na X3D (Daly e Brutzman, 2010), que foi construída com base na linguagem VRML (Carey e Bell, 1997). Esta linguagem dispõe de recursos avançados de áudio, vídeo, navegação e interação com o usuário, que facilitaram a sua adoção.
Para prover uma infraestrutura de banco de dados nas nuvens, adotou-se a solução chamada NuoDB (Brynko, 2012), que possui foco em ambientes de dados geo-distribuídos, sendo considerado um Cloud Database, contando com cache distribuída e durável, baseada em replicação sob demanda (Lemos, 2014; Brynko, 2012).
Desta maneira, pode-se ter um ambiente como representado na arquitetura (Figura 16), na qual pode-se ter diversas instâncias públicas e privadas com componentes à disposição do framework.
Por fim, para realizar o acesso do NuoDB, foi utilizado a Java Persistence API (JPA), que é uma Application Programming Interface (API) e que atua no mapeamento objeto-relacional (MOR). Esta API permite a representação de conceitos em Banco de Dados para conceitos de Orientação a Objetos (OO), facilitando a manipulação dos dados, na qual as consultas são facilitadas pela API por meio da manipulação de objetos (Keith et al., 2013).
3.2.2 Módulo Cliente (Browser)
Conforme abordado anteriormente, o cliente (browser) representa a diversidade de sistemas na área de RV que podem consumir os recursos dos componentes disponibilizados pelo servidor, na qual tem-se o repositório dos componentes.
No entanto, para que o browser consiga incorporar as funcionalidades dos componentes, definimos este framework de forma a fornecer uma estrutura padrão para consumo dos componentes. Apresentada na Figura 19 a arquitetura interna do browser.
Figura 19: Arquitetura Interna do Browser
Fonte: O Autor
As funcionalidades relativas ao gerenciamento dos ambientes tridimensionais estão presentes no módulo principal, ou seja, representa a implementação dos browsers que usarão o AvComponent.
Para validar o funcionamento da arquitetura, foi utilizado o toolkit Xj3d (Hudson et al., 2002), que trabalha com ambientes descritos na linguagem X3D, entretanto quaisquer outros toolkits para gerenciamento de ambientes tridimensionais escritos na linguagem Java (Gosling, 2000) podem ser usados.
No módulo Task estão relacionados todos os recursos que permitem a associação dinâmica de componentes de RV, que durante este trabalho foram nomeados de tasks, que podem ser componentes de software, assim como de ambientes tridimensionais.
Este módulo é composto pelo componente chamado Task Manager, que após a leitura de um descritor de implantação (i.e. browser.xml) que é implementado na linguagem XML, efetuará uma associação adequada das tasks ao browser com base em regras previamente definidas. Este processo de associação é apresentado na Figura 20.
