UMS – 27, UMS – 28 ve UMS – 31 Đle Đlgili Çözüm Önerileri

Este cap´ıtulo descreve as atividades conduzidas para a cria¸c˜ao da M-SPLearning (Mobile Software Product Line for Learning), que representa uma LPS definida no dom´ınio das aplica¸c˜oes para m-learning, com a inten¸c˜ao de atingir os objetivos propostos por este trabalho.

A partir dessa LPS ´e poss´ıvel gerar aplica¸c˜oes m-learning personalizadas de forma sistem´atica, provendo um ambiente seguro e compartilhado entre professores e alunos. Em termos pr´aticos, os pr´oprios tutores podem utilizar a M-SPLearning para gerar uma aplica¸c˜ao educacional m´ovel personalizada e, posteriormente, distribu´ı-la para seus alunos. A Se¸c˜ao 3.2 apresenta a Engenharia de Dom´ınio realizada para o projeto e imple- menta¸c˜ao da M-SPLearning evidenciando sua capacidade produtiva atrav´es das seguintes atividades secund´arias: (i) An´alise de Dom´ınio; (ii) Defini¸c˜ao da Arquitetura; (iii) Pro- jeto de Componentes; e (iv) Plano de Produ¸c˜ao. Em seguida, na Se¸c˜ao 3.3, a Engenharia de Aplica¸c˜ao apresenta os detalhes sobre a gera¸c˜ao das aplica¸c˜oes educacionais m´oveis a partir da LPS especificada.

3.2

Engenharia de Dom´ınio

Durante a atividade de Engenharia de Dom´ınio as similaridades e variabilidades devem ser elicitadas para o desenvolvimento da LPS, com o objetivo de estabelecer uma plataforma sistematicamente reutiliz´avel. O resultado desta atividade ´e um conjunto de ativos com os quais a LPS deve ser implementada, caracterizando assim sua fam´ılia de produtos (B¨ockle et al., 2005; Clements e Northrop, 2002; van der Linden et al., 2007).

De modo geral, as atividades que caracterizam a Engenharia de Dom´ınio podem ser consideradas as mais cr´ıticas na concep¸c˜ao de uma LPS. De fato, delimitar uma ´area de estudo n˜ao ´e uma tarefa simples, visto que o pr´oprio significado de dom´ınio induz a um entendimento aberto e permite interpreta¸c˜oes abrangentes.

De fato, para que uma LPS seja bem sucedida, seu dom´ınio deve ser definido com cuidado. Se o escopo for muito grande, os artefatos centrais ser˜ao estendidos para al´em de uma variabilidade manuten´ıvel, economias de produ¸c˜ao ser˜ao perdidas e a LPS entrar´a em colapso. Por outro lado, se o escopo for muito pequeno, os ativos centrais podem n˜ao ser desenvolvidos de um modo gen´erico o suficiente para acomodar evolu¸c˜oes futuras, fazendo com que a LPS n˜ao evolua (B¨ockle et al., 2005; Clements e Northrop, 2002; van der Linden et al., 2007).

No contexto deste trabalho, para a defini¸c˜ao de um dom´ınio tang´ıvel, foi necess´ario restringir a pesquisa a um ´unico sistema operacional. Uma das principais informa¸c˜oes para apoiar essa escolha foi a quantidade de dispositivos comercializados no mercado, visto que esse dado influencia diretamente na quantidade de usu´arios potenciais para as aplica¸c˜oes m-learning geradas pela M-SPLearning. Desta forma, o dom´ınio considerado foi restrito `a plataforma Android, respons´avel pelo controle de 78,6% dos smartphones vendidos em 2013, o equivalente a 793,6 milh˜oes de dispositivos (Llamas et al., 2013).

Al´em disso, uma das publica¸c˜oes relacionadas a esta pesquisa teve como objetivo com- parar as tecnologias HTML5 e Android experimentalmente. No entanto, seus resultados n˜ao foram expressivos o suficiente a ponto de influenciar na defini¸c˜ao do dom´ınio em quest˜ao.

A partir da defini¸c˜ao do dom´ınio, surgiu a necessidade da elicita¸c˜ao das necessidades de neg´ocio. Nesse sentido, Duarte Filho e Barbosa (2013) conduziram uma revis˜ao siste- m´atica, cujo principal resultado foi um cat´alogo (conjunto) de requisitos voltado para o desenvolvimento de ambientes de aprendizagem m´ovel. Os requisitos em quest˜ao foram elicitados com o objetivo de prover as informa¸c˜oes necess´arias para a cria¸c˜ao de uma ar- quitetura de referˆencia para ambientes de aprendizagem m´ovel (Duarte Filho e Barbosa, 2014).

De acordo com Duarte Filho e Barbosa (2013), o cat´alogo proposto pode capturar as necessidades, expectativas e restri¸c˜oes n˜ao s´o para os desenvolvedores de ambientes de aprendizagem m´ovel, mas tamb´em para aqueles que o utilizam no seu dia a dia, sendo eles tutores ou aprendizes.

Em termos de dom´ınio, aplica¸c˜oes educacionais m´oveis est˜ao diretamente relacionadas a ambientes de aprendizagem m´ovel. O cat´alogo tem a inten¸c˜ao de refletir, em alto n´ıvel, a experiˆencia adquirida por desenvolvedores e pesquisadores no amplo dom´ınio dos ambientes m-learning. Na pr´atica, sua composi¸c˜ao gen´erica e abrangente faz com que seus requisitos sejam aplic´aveis a diferentes subdom´ınios, inclusive o de aplica¸c˜oes m-learning sob a plataforma Android.

De modo geral, o cat´alogo mostrou-se abrangente e gen´erico, o que favorece sua ade- qua¸c˜ao a diferentes dom´ınios nos contextos educacionais e de mobilidade. Por esse motivo, seus requisitos foram utilizados como base para a Engenharia de Dom´ınio da M-SPLear ning.

Os modelos de ado¸c˜ao propostos por Krueger (2002) tamb´em foram analisados com o objetivo de identificar o modelo mais adequado ao contexto da M-SPLearning. As caracter´ısticas do dom´ınio em quest˜ao, associadas `a existˆencia do cat´alogo de requisitos de Duarte Filho e Barbosa (2013), motivaram a escolha do modelo proativo de Krueger (2002) devido ao conhecimento pr´evio relacionado ao dom´ınio da LPS proposta. Com isso, foi adotado um processo sistem´atico para concep¸c˜ao da M-SPLearning, caracterizado por quatro atividades, descritas a seguir.

3.2.1

An´alise de Dom´ınio

De acordo com o modelo de ado¸c˜ao proativo proposto por Krueger (2002), primeiramente ´e realizada a An´alise de Dom´ınio e escopo, com o prop´osito de identificar a varia¸c˜ao dos produtos apoiados pela LPS. Para isso, o cat´alogo de requisitos proposto por Duarte Filho e Barbosa (2013) foi confrontado com o modelo de qualidade ISO/IEC 25010 (ISO e IEC, 2011), com o objetivo de identificar requisitos de qualidade ausentes ou desconexos.

A partir dessa an´alise alguns requisitos foram reagrupados, renomeados e, em menor propor¸c˜ao, adicionados e removidos no cat´alogo de Duarte Filho e Barbosa (2013). Essas modifica¸c˜oes consideraram o escopo e dom´ınio definidos para a M-SPLearning, gerando assim uma deriva¸c˜ao do cat´alogo de requisitos original, ilustrado na Figura 3.1.

A partir do cat´alogo derivado, observou-se que a maioria dos requisitos propostos por Duarte Filho e Barbosa (2013) eram equivalentes, direta ou indiretamente, `as caracter´ısti- cas e subcaracter´ısticas da norma ISO/IEC 25010. Com isso, acredita-se que a deriva¸c˜ao realizada forneceu os requisitos educacionais m´oveis necess´arios para a concep¸c˜ao da LPS deste trabalho.

Figura 3.1: M-SPLearning: Cat´alogo de requisitos derivado.

Em termos estruturais, o cat´alogo resultante apresentou 10 requisitos prim´arios e 35 secund´arios. Tendo como exemplo o elemento Support, que apresenta caracter´ısticas secund´arias bastante comuns como a internacionaliza¸c˜ao de mensagens (caracter´ıstica provida pelo requisito Customization) e a disponibiliza¸c˜ao de d´uvidas frequentes (Help). Apesar de possuir requisitos gen´ericos e aplic´aveis a outros dom´ınios, o cat´alogo deri- vado tamb´em possui caracter´ısticas espec´ıficas para aplica¸c˜oes m-learning. Por exemplo, a maior parte dos requisitos derivados de Pedagogical e Communication representam ne- cessidades essenciais ao dom´ınio educacional m´ovel.

Em termos pedag´ogicos, o gerenciamento de conte´udos educativos ´e fundamental para o desenvolvimento das atividades educacionais. Al´em disso, a presen¸ca de recursos multi- m´edia pode proporcionar acesso a informa¸c˜ao de forma mais atrativa. Tais peculiaridades sintetizam os requisitos classificados pelo item Pedagogical.

Por sua vez, os requisitos provenientes de Communucation representam funcionalida- des relacionadas `a troca de mensagens, alertas e o compartilhamento de resultados ou feedbacks, tornando o aprendizado mais colaborativo e dinˆamico. Outra caracter´ıstica importante ´e a sincroniza¸c˜ao dos dados de uma aplica¸c˜ao m-learning, j´a que os usu´arios podem possuir e utilizar mais de um dispositivo m´ovel.

Com o objetivo de avaliar o cat´alogo de requisitos proposto para a M-SPLearning, uma atividade adicional de valida¸c˜ao foi conduzida. Nesse sentido, um formul´ario foi elaborado com o objetivo de verificar informalmente as principais quest˜oes t´ecnicas relacionadas ao

cat´alogo de requisitos em quest˜ao. O formul´ario foi disponibilizado online, seguindo uma estrutura de checklist, com o intuito de mensurar as opini˜oes de especialistas na ´area de engenharia de software.

O documento contou com 12 quest˜oes de m´ultipla escolha, onde as duas primei- ras perguntas eram relacionadas `a experiˆencia dos participantes nos conceitos de LPS e m-learning. Nesse caso, as op¸c˜oes poss´ıveis foram: “Proficiente”, “Intermedi´ario” e “No- vato”. As dez quest˜oes restantes referiam-se ao cat´alogo de requisitos da M-SPLearning, por exemplo: “O cat´alogo ´e composto por requisitos adequados ao dom´ınio?”. Para essas perguntas as op¸c˜oes “Adequado”, “Regular” e “Insatisfat´orio” foram aplicadas.

Para aplica¸c˜ao do formul´ario, alguns grupos de pesquisa foram notificados via e-mail com um convite para o preenchimento volunt´ario do checklist. Ap´os alguns dias o formu- l´ario foi finalizado com um total de 11 participantes.

Os resultados coletados mostraram que, na vis˜ao dos participantes, o cat´alogo de re- quisitos est´a adequado ou regular a todos os itens avaliados. Al´em disso, nenhuma das quest˜oes relacionadas ao cat´alogo de requisitos da M-SPLearning foi respondida como in- satisfat´oria. A Tabela 3.1 sintetiza as avalia¸c˜oes m´edias obtidas a partir dos 11 formul´arios de checklist submetidos.

Tabela 3.1: M-SPLearning: Sum´ario da avalia¸c˜ao do cat´alogo de requisitos. Op¸c˜ao Porcentagem M´edia Obtida

Adequado 60.90%

Regular 39.10%

Insatisfat´orio 0.00%

A sumariza¸c˜ao dos resultados, apesar de positiva, foi considerada uma valida¸c˜ao pre- liminar, visto que o preenchimento de um checklist anˆonimo n˜ao caracteriza uma t´ecnica de valida¸c˜ao formal. Desta forma, o checklist proposto consiste em uma valida¸c˜ao inicial que, em poss´ıveis trabalhos futuros, deve ser complementada com novas t´ecnicas. Toda- via, esta atividade de valida¸c˜ao foi importante para avaliar o artefato que sintetizou os requisitos elicitados para a M-SPLearning.

Com base na defini¸c˜ao de Krueger (2002), a pr´oxima etapa da atividade de An´alise de Dom´ınio consiste em identificar as variabilidades incorporadas pelos produtos da LPS, na qual a abordagem proativa est´a sendo aplicada.

De acordo com Van Gurp et al. (2001), as variabilidades representam a forma pela qual os produtos de uma LPS s˜ao diferenciados e sua aplica¸c˜ao torna poss´ıvel a gera¸c˜ao dos produtos espec´ıficos apoiados pela LPS. Em termos pr´aticos, Bosch (2001) e Kang et al. (1990) afirmam que as variabilidades geralmente s˜ao identificadas e representadas por meio do conceito de features.

Uma feature, por sua vez, representa uma caracter´ıstica de um sistema que ´e relevante e vis´ıvel ao usu´ario final (Kang et al., 1990). Usualmente s˜ao representadas por um modelo de features, que consiste em uma representa¸c˜ao hier´arquica das variabilidades e similaridades de um determinado dom´ınio. No contexto da M-SPLearning, o cat´alogo de requisitos foi analisado e suas caracter´ısticas serviram como base para a cria¸c˜ao de um modelo de features aderente aos requisitos elicitados (Figura 3.2).

Figura 3.2: M-SPLearning: Modelo de features.

A interpreta¸c˜ao do modelo de features ´e simples e segue os conceitos tradicionais idea- lizados por Kang et al. (1990) na abordagem FODA. Basicamente, cada requisito concreto presente no cat´alogo da M-SPLearning foi transformado em uma feature prim´aria. Com isso, foram modeladas 16 features obrigat´orias e 14 features opcionais.

Com rela¸c˜ao ao cat´alogo, alguns dos requisitos elicitados mostraram-se muito abs- tratos ou onipresentes em rela¸c˜ao ao dom´ınio educacional m´ovel e, por isso, n˜ao foram

transformados em features, s˜ao eles: (i) Functional ; (ii) Portability; (iii) Efficiency; e (iv) Maintainability.

As features prim´arias e suas respectivas responsabilidades no dom´ınio das aplica¸c˜oes m-learning s˜ao apresentadas a seguir, sintetizando as contribui¸c˜oes da An´alise de Dom´ınio: ❼ Pedagogical: Incorpora requisitos educacionais e pedag´ogicos, provendo as princi- pais caracter´ısticas presentes em aplica¸c˜oes m-learning para atividades de ensino e treinamento. A subfeature Interactivity ´e opcional, uma vez que est´a relacionada a interatividade via redes sociais e similares. As subfeatures Content Management, Educational Activities e Multimedia Resources s˜ao obrigat´orias, onde a ´ultima de- las possibilita a escolha de um ou mais recursos multim´edia como apoio ao ensino. Al´em disso, essa feature prevˆe a autoria das aplica¸c˜oes m-learning geradas e de seus respectivos conte´udos educacionais.

❼ Usability: Apresenta caracter´ısticas essenciais no que diz respeito `a interface visual de um produto. Tais caracter´ısticas s˜ao fundamentais para a aceita¸c˜ao do software no mercado. Essa feature e suas varia¸c˜oes garantem que todos os produtos gerados pela LPS sigam um padr˜ao de usabilidade que agregue qualidade aos usu´arios finais. Com isso, todas as features em quest˜ao foram definidas como obrigat´orias.

Na plataforma Android existem diversas imposi¸c˜oes em termos de usabilidade, com o objetivo de padronizar e maximizar a experiˆencia de seus usu´arios, por este motivo as features em quest˜ao foram definidas como abstratas.

❼ Compatibility: Engloba a coexistˆencia e capacidade de um produto trocar informa- ¸c˜oes com outros sistemas no mesmo ambiente operacional. Por se mostrar essencial a aplicativos m´oveis, essas features foram definidas como obrigat´orias.

❼ Security: Trata-se de uma feature fundamental para qualquer aplicativo educaci- onal m´ovel, uma vez que existem aspectos que devem ser garantidos para que os usu´arios confiem no produto gerado. A importˆancia das features que representam a integridade e confidencialidade fez com que elas fossem definidas como obrigat´orias. J´a a feature Authenticity ´e opcional porque nem todo aplicativo m-learning possui autentica¸c˜ao expl´ıcita de seus usu´arios.

❼ Communication: Provˆe o transporte de informa¸c˜oes entre os usu´arios do aplicativo, possibilitando troca de mensagens, divulga¸c˜ao de resultados de testes e at´e mesmo a sincroniza¸c˜ao de atividades realizadas em outros dispositivos m´oveis. Essa fea- ture ´e opcional e suas subfeatures possuem esta mesma defini¸c˜ao, ou seja, qualquer combina¸c˜ao poss´ıvel entre elas ´e suportada pela M-SPLearning.

❼ Support: Trata-se de uma feature considerada um diferencial de qualidade para os produtos que a incorporam, pois provˆe alternativas de apoio ao usu´ario, como ajuda e internacionaliza¸c˜ao. Foi classificada como opcional por n˜ao caracterizar um pr´e-requisito, assim como suas subfeatures.

3.2.2

Defini¸c˜ao da Arquitetura

A partir do modelo de features definido anteriormente, foi poss´ıvel definir uma arquitetura de software aderente `as necessidades do dom´ınio educacional m´ovel. Tal arquitetura e seus respectivos componentes representam, de forma abstrata, os ativos centrais da M-SPLear ning.

Durante a atividade de Defini¸c˜ao da Arquitetura surgiu a necessidade de elaborar uma representa¸c˜ao arquitetural para a LPS proposta. Nesse sentido, a maioria das abordagens desenvolvidas para auxiliar no gerenciamento de variabilidades envolvem diversos concei- tos e modelos de representa¸c˜ao. A abordagem SMarty, em especial, possui como base a UML, amplamente aceita pela comunidade cient´ıfica. Com isso, devido a sua facilidade de uso e resultados experimentalmente avaliados (Marcolino et al., 2014a,b, 2013) a SMarty foi escolhida para apoiar esta atividade da M-SPLearning.

A abordagem SMarty foi essencial durante todo o processo de desenvolvimento da LPS proposta, sobretudo por agregar seu perfil aos modelos UML para representa¸c˜ao das similaridades e, principalmente, das variabilidades da M-SPLearning, como ´e o caso do diagrama de componentes arquiteturais ilustrado na Figura 3.3.

Com base no diagrama arquitetural ´e poss´ıvel identificar a base estrutural utilizada para a constru¸c˜ao da M-SPLearning. O pacote com os ativos centrais engloba os compo- nentes que representam as features definidas como concretas no modelo de features.

Os componentes que representam features espec´ıficas do dom´ınio m-learning foram agrupados e intitulados como core. Assim, foi poss´ıvel unificar os m´odulos fundamentais a qualquer produto gerado pela M-SPLearning. Al´em disso, ´e poss´ıvel identificar alguns dos elementos da abordagem SMarty, que nesse caso representam as variabilidades da LPS em alto n´ıvel.

A camada de aplica¸c˜ao, por sua vez, cont´em um componente que representa a M-SPLear ning, identificando sua associa¸c˜ao com os ativos centrais e explicitando a possibilidade de cria¸c˜ao de m´ultiplos produtos, tamb´em representados como componentes. Cada produto gerado utiliza as dependˆencias dispon´ıveis nos ativos centrais, fazendo com que cada pro- duto possa utilizar dependˆencias diferentes de acordo com as configura¸c˜oes definidas na M-SPLearning.

A pr´oxima se¸c˜ao apresenta a atividade seguinte, que detalha cada um dos componentes representando-os como ativos centrais da M-SPLearning. O objetivo ´e detalhar suas

Figura 3.3: M-SPLearning: Arquitetura (diagrama de componentes SMarty). similaridades e variabilidades para a defini¸c˜ao do Plano de Produ¸c˜ao, ´ultima atividade da An´alise de Dom´ınio.

3.2.3

Projeto de Componentes

Segundo Krueger (2002), esta fase deve ser conduzida para projetar as variabilidades e similaridades identificadas pela An´alise de Dom´ınio. Nesse sentido, os componentes, ar- quitetonicamente armazenados junto aos ativos centrais, tiveram suas respectivas features visualmente representadas por meio de um diagrama de componentes SMarty, ilustrado na Figura 3.4.

Por meio desse diagrama de componentes ´e poss´ıvel visualizar detalhadamente todas as features concretas contempladas pela M-SPLearning, as quais foram rotuladas com os estere´otipos caracter´ısticos da abordagem SMarty. O modelo em quest˜ao facilitou, em termos cognitivos, a visualiza¸c˜ao da dimens˜ao de configura¸c˜oes poss´ıveis aos aplicativos m-learning contemplados pela LPS.

Por exemplo, o componente multimedia foi modelado como uma variabilidade (estere´o- tipo <<variability>>), ou seja, ele pode ser configurado para que uma LPS crie aplica¸c˜oes m-learning personalizadas de acordo com suas configura¸c˜oes. Dessa forma, uma aplica¸c˜ao poderia ser configurada para possuir no m´ınimo um e no m´aximo quatro recursos multi- m´edia (audio, image, text e video), conforme as nota¸c˜oes “minSelection” e “maxSelection”.

Note que, segundo as pr´aticas da SMarty, qualquer componente cujo filho foi modelado como uma variabilidade deve ser marcado como vari´avel (estere´otipo <<variable>>).

Com ˆenfase no dom´ınio explorado, os componentes pedagogical e communication me- recem destaque, assim como seus requisitos. Nesse sentido, a maioria dos componentes pedag´ogicos s˜ao obrigat´orios, com variabilidades poss´ıveis em termos de interatividade e recursos multim´ıdia (j´a explanada anteriormente). Por sua vez, os componentes agrupa- dos em communication s˜ao alternativos, sendo que ao menos um deles deve agregar sua funcionalidade aos produtos gerados.

Tamb´em fica expl´ıcito o relacionamento de dependˆencia entre os componentes mode- lados. Como definido anteriormente, o componente core unifica as features integralmente obrigat´orias ao dom´ınio m-learning, tornando-se necess´ario, direta ou indiretamente, aos componentes security, communication e support. A particularidade aqui fica por conta do componente communication, dependente do componente security, que por sua vez est´a relacionado com o componente core, fazendo com que o componente communication tam- b´em tenha acesso a essa dependˆencia. Isso garante a imposi¸c˜ao arquitetˆonica de que todos os componentes parcialmente mandat´orios ou opcionais dependam do componente core, que prover´a as caracter´ısticas fundamentais da M-SPLearning.

A partir do Projeto de Componentes aferidos pela LPS, torna-se poss´ıvel a defini¸c˜ao de um Plano de Produ¸c˜ao que transforme as representa¸c˜oes abstratas em produtos de software concretos, com suas respectivas variabilidades. A se¸c˜ao a seguir conclui a An´alise de Dom´ınio definida para a M-SPLearning.

3.2.4

Plano de Produ¸c˜ao

O Plano de Produ¸c˜ao prescreve como os produtos devem ser gerados a partir dos ativos centrais definidos para a LPS. Para isso, um diagrama de atividades usando a abordagem SMarty foi modelado, expondo as variabilidades poss´ıveis durante o processo de cria¸c˜ao de um produto (Figura 3.5). Basicamente, este plano pode ser considerado um ativo central da M-SPLearning, assim como qualquer outro artefato que contribua para a cria¸c˜ao sistem´atica de seus produtos.

O ponto de varia¸c˜ao definido no plano de produ¸c˜ao exp˜oe todas as variabilidades elicitadas para a M-SPLearning. Desta forma, a personaliza¸c˜ao dos produtos foi centrali- zada em um ´unico ponto, agilizando o processo de configura¸c˜ao e gera¸c˜ao dos aplicativos m-learning, provenientes da LPS proposta.

Cada raia do diagrama representa um m´odulo espec´ıfico, sendo poss´ıvel identificar al-