WTDSoft - CBSoft 2013 - Universidade de Brasília
Transcrição
WTDSoft - CBSoft 2013 - Universidade de Brasília
Congresso Brasileiro de Software: Teoria e Prática 29 de setembro a 04 de outubro de 2013 Brasília-DF Anais WTDSOFT 2013 III WORKSHOP DE TESES E DISSERTAÇÕES DO CBSOFT WTDSOFT 2013 1º de outubro de 2013 Brasília-DF, Brasil ANAIS COORDENAÇÃO DO WTDSOFT 2013 Volume 01 ISSN: 2178-6097 Fernando Magno Quintão Pereira COORDENAÇÃO DO CBSOFT 2013 Genaína Rodrigues – UnB Rodrigo Bonifácio – UnB Edna Dias Canedo - UnB REALIZAÇÃO Universidade de Brasília (UnB) Departamento de Ciência da Computação (DIMAp/UFRN) PROMOÇÃO Sociedade Brasileira de Computação (SBC) PATROCÍNIO CAPES, CNPq, Google, INES, Ministério da Ciência, Tecnologia e Inovação, Ministério do Planejamento, Orçamento e Gestão e RNP APOIO Instituto Federal Brasília, Instituto Federal Goiás, Loop Engenharia de Computação, Secretaria de Turismo do GDF, Secretaria de Ciência Tecnologia e Inovação do GDF e Secretaria da Mulher do GDF WTDSOFT 2013 Autorizo a reprodução parcial ou total desta obra, para fins acadêmicos, desde que citada a fonte 3 WTDSOFT 2013 APRESENTAÇÃO O III Workshop de Teses e Dissertações do CBSoft (WTDSoft 2013) é um evento permanente associado ao Congresso Brasileiro de Software: Teoria e Prática (CBSoft). O workshop destinasse à apresentação e à discussão de trabalhos de mestrado e doutorado em andamento nas áreas de Engenharia de Software, Linguagens de Programação e Métodos Formais. Assim, muito mais que um meio em que ciência possa ser divulgada, o WTDSoft é um ambiente em que ela pode ser discutida. Dessa discussão espera-se que surjam novas idéias que permitam ao palestrante melhorar seu trabalho, aprofundar seu conhecimento sobre o tema em que faz pesquisa, e travar contato com outros pesquisadores da área. Este ano foram aceitos dezenove trabalhos para o workshop, provenientes de diversos programas de pós-graduação brasileiros. Esses trabalhos serão apresentados entre os dias 30 de Setembro e 1 de Outubro. Desejamos a todos os palestrantes, e a sua audiência, que esses dois dias sejam produtivos para seus trabalhos, e que esses possam contribuir para a solidificação da pesquisa em software no país. 4 WTDSOFT 2013 BIOGRAFIA DO COORDENADOR / CHAIRS SHORT BIOGRAPHIES FERNANDO MAGNO QUINTÃO PEREIRA Fernando possui graduação em Ciência da Computação pela Universidade Federal de Minas Gerais (2001), mestrado em Ciência da Computação pela Universidade Federal de Minas Gerais (2003) e doutorado pela Universidade da California em Los Angeles (2008). Seus interesses incluem problemas relacionados à análise e otimização de código. 5 WTDSOFT 2013 COMITÊS TÉCNICOS / TECHNICAL COMMITTEES Adenilso Simao Adolfo Duran Alberto Costa Neto Alessandro Garcia Andre Endo Arnaldo Moura Cecilia Rubira Christina Chavez Edson Borin Eduardo Figueiredo Everton Guimaraes Fernando Castor Fernando Quintao Pereira Francisco Carvalho-Junior Franklin Ramalho Gledson Elias Leila Silva Marcelo dAmorim Patricia Machado Paulo Masiero Raul Wazlawick Rohit Gheyi Rosângela Penteado Silvia Vergilio Tayana Conte Uirá Kulesza 6 WTDSOFT 2013 ÍNDICE DE ARTIGOS / TABLE OF CONTENTS ABORDAGEM DIRIGIDA POR MODELOS PARA A GERAÇÃO DE SISTEMAS UBÍQUOS DE APRENDIZAGEM, UMA 9 ABORDAGEM HÍBRIDA PARA GERAÇÃO DE PORTFÓLIOS EM LINHAS DE PRODUTO DE SOFTWARE, UMA 10 ABORDAGEM SENSÍVEL AO CONTEXTO PARA VISUALIZAÇÃO EM CENÁRIOS DE DESENVOLVIMENTO DE SOFTWARE, UMA 17 APRIMORANDO A VERIFICAÇÃO DE CONFORMIDADE EM PROGRAMAS UTILIZANDO A METODOLOGIA DESIGN BY CONTRACT 23 CONFIGURAÇÃO DE PRODUTOS EM LINHA DE PRODUTOS DE SOFTWARE 29 CRITÉRIOS E DIRETRIZES PARA O DESENVOLVIMENTO DE SISTEMAS MANUTENÍVEIS EM LINHAS DE PRODUTOS DE SOFTWARE 35 EXTRAÇÃO DE CONHECIMENTO E EXPERIÊNCIAS EM EQUIPES DE DESENVOLVIMENTO DISTRIBUÍDO DE SOFTWARE 40 IDENTIFICAÇÃO DE BAD SMELLS EM SOFTWARES A PARTIR DE MODELOS UML 45 INFRAESTRUTURA PARA CRIAÇÃO DE JOGOS VOLTADOS PARA O ENSINO DE PROGRAMAÇÃO NO ENSINO MÉDIO 53 META-FERRAMENTA PARA APOIO AO REUSO NA DEFINIÇÃO DE PROCESSOS DE SOFTWARE PADRÃO POR ORGANIZAÇÕES CONSULTORAS, UMA 58 MÉTODO PARA AVALIAÇÃO DA QUALIDADE DO MODELO DE FEATURES EM LINHAS DE PRODUTOS DE SOFTWARE UTILIZANDO MEDIDAS, UM 63 MINING PRODUCT RISKS TO SUPPORT RISK-BASED TESTING 71 NON-TERMINATION ATTACKS BASED ON INTEGER OVERFLOWS 78 ODYSSEYPRLE-CBARCH: A PROCESS REUSE APPROACH COMBINING THE SOFTWARE PROCESS LINE AND PROCESS COMPONENT BASED ARCHITECTURE APPROACHES 86 7 WTDSOFT 2013 OTIMIZAÇÕES DE CÓDIGO SENSÍVEIS AO CONTEXTO DE CHAMADA 92 PROPOSTA PARA GERAÇÃO AUTOMÁTICA DE TESTES PARA LINHAS DE PRODUTO DE SOFTWARE SENSÍVEIS AO CONTEXTO, UMA 100 RECCLOUD: UM SISTEMA DE RECOMENDAÇÃO BASEADO EM NUVEM 106 VALIDAÇÃO EXPERIMENTAL DA ABORDAGEM SMARTY PARA GERENCIAMENTO DE VARIABILIDADE EM LINHA DE PRODUTO DE SOFTWARE 112 XDTV: UM MÉTODO ÁGIL PARA O DESENVOLVIMENTO DE APLICAÇÕES PARA TV DIGITAL 118 8 Uma Abordagem Dirigida por Modelos para a Geração de Sistemas Ubíquos de Aprendizagem Edgar M. Barros Filho, Rossana M. C. Andrade, Windson Viana Grupo de Redes de Computadores, Engenharia de Software e Sistemas – GREat Universidade Federal do Ceará, Fortaleza - CE, Brasil [email protected], [email protected], [email protected] Abstract. One of the advantages of Model-Driven Software Engineering is to simplify and improve the generation of software through the use of models that effectively express the concepts of a specific domain. Considering the Ubiquitous Learning paradigm, which proposes the use of computing resources in ubiquitous learning activities, particular challenges arise for the construction of such system, as the perception of the student´s context , the record of activities considering user mobility and the content accessibility regardless the location, time and device used. Thus, this paper proposes an approach based on Model-Driven Software Engineering for automated generation of systems for Ubiquitous Learning. Resumo. Uma das vantagens da Engenharia de Software Dirigida por Modelos é simplificar e aperfeiçoar a geração de software através da utilização de modelos que expressem efetivamente os conceitos específicos de um domínio. Considerando o paradigma Ubiquitous Learning, que propõe o uso de recursos da computação ubíqua em atividades de aprendizagem, desafios particulares surgem para a construção desse tipo de sistema, como a percepção do contexto do aluno, o registro das atividades considerando a mobilidade dos usuários e o acesso aos conteúdos, independente do local, momento ou dispositivo utilizado. Desta forma, este trabalho propõe uma abordagem baseada na Engenharia de Software Dirigida por Modelos para a geração automatizada de sistemas para Ubiquitous Learning. 1. Caracterização do Problema O uso de modelos de software eleva o nível de abstração no processo de desenvolvimento, possibilitando a representação efetiva dos conceitos específicos de um domínio e a redução da complexidade na criação de sistemas. Pesquisadores das áreas de engenharia de software e educação têm desenvolvido, em conjunto, iniciativas para geração de conteúdo digital online na Internet a partir de modelos [Figl et al. 2010]. Em se tratando de modelagem educacional, a linguagem IMS-LD [Koper e Miao 2008] tem se destacado, pois através dela se pode construir modelos que representam os participantes, as interações e os relacionamentos em uma atividade de aprendizagem. A IMS-LD, como outras linguagens de modelagem educacional, é empregada, sobretudo para a representação de atividades de aprendizagem que são acessadas via web e ainda pouco explorada para outras plataformas ou paradigmas computacionais. Por outro lado, a computação ubíqua propõe o uso de dispositivos de diferentes formatos e funções para auxiliar as pessoas na realização de suas atividades cotidianas, de forma coordenada e autônoma [Rocha et al. 2011 ] e o paradigma Ubiquitous 9 Learning (ou U-Learning) preconiza o uso dos recursos de computação ubíqua para apoiar atividades de ensino e aprendizagem. O desenvolvimento de sistemas de U-Learning, entretanto, não é trivial. Esses sistemas padecem das mesmas necessidades dos sistemas ubíquos, tais como: Coordenação, Descoberta/Descrição de Serviços, Interoperabilidade, Sensibilidade ao Contexto e Autonomicidade [Rocha 2013]. Além desses aspectos, apresentam também questões específicas que ampliam a dificuldade na sua construção, por exemplo, a metodologia pedagógica e as formas de avaliação do progresso e da aprendizagem dos alunos. As ferramentas atuais de modelagem e geração de conteúdo exigem um nível de conhecimento técnico que dificultam que grande parte dos especialistas de área (e.g., professores) faça o projeto das atividades de aprendizagem para práticas auxiliadas por recursos computacionais. Isto se agrava quando se considera as características dos sistemas de U-Learning, não previstas na maioria dessas ferramentas. Este trabalho tem então como objetivo principal o desenvolvimento de uma abordagem, baseada na engenharia de software dirigida por modelos, para geração de sistemas de U-Learning a partir de representações próximas do seu domínio de conhecimento. Para isso, pretende-se elaborar modelos, ferramentas e métodos para representar as atividades de aprendizagem, executá-las em campo e avaliar a abordagem proposta como um todo. 2. Fundamentação Teórica Nos últimos anos, têm aumentado o número de iniciativas que empregam os recursos da computação ubíqua em atividades de aprendizagem, com destaque para atividades fora da sala de aula [Huang et al., 2011; Wen et al., 2013; Lee et al. 2013]. Esse paradigma, conhecido como Ubiquitous Learning ou U-Learning, propõe que os estudantes possam aprender em qualquer lugar e a qualquer momento através de serviços, informações e facilidades computacionais, de forma que a infraestrutura não esteja visível. Além disso, esses sistemas devem perceber o contexto do aluno e fornecer conteúdo adaptado para ele. Outras características que esses sistemas devem prever são: Permanência, que consiste na manutenção do registro das atividades dos alunos; Acessibilidade, para permitir que o aluno possa acessar conteúdo de forma remota e independentemente do dispositivo e local que está acessando; Urgência, para permitir que o aluno possa recuperar suas informações no momento que ele precisar; e Interatividade, para permitir que os alunos interajam entre si e com o professor [Ogata e Yano, 2004]. Algumas experiências com o uso de tecnologias móveis e ubíquas já apresentaram impacto positivo em diferentes contextos de aprendizagem.. Por exemplo, Spikol & Milrad [Spikol & Milrad, 2008] integraram o tradicional jogo de Geocaching com tecnologias móveis para desenvolver um sistema de aprendizagem ao ar livre. O sistema de navegação fornece mapas e materiais de aprendizagem interativa, a fim de promover a motivação dos alunos nos processos de aprendizagem. Costa et al. [Costa et al. 2002] demonstram que a introdução da computação móvel na sala de aula motiva o aprendizado, a colaboração e a comunicação entre os alunos. Bichard & Waern [Bichard & Waern, 2008] desenvolveram experiências de aprendizagem através do uso de tecnologia móvel, integrando GPS e realidade aumentada, a fim de criar um cenário envolvente para que os alunos se beneficiem da sua experiência no jogo. 10 Estudos têm sido desenvolvidos no sentido de aproveitar os benefícios da ModelDriven Software Engineering (ou Model-Driven Engineering – MDE) para construção de sistemas ubíquos. Em MDE, os modelos tornam-se os artefatos primários no ciclo de vida do software. A partir deles, podem ser feitas simulações, tomadas de decisão e geração do código-fonte de aplicações [Williams et al. 2012]. Várias iniciativas têm sido desenvolvidas em Model Driven Engineering. O OMG (Object Management Group) propôs uma abordagem padrão para desenvolvimento de sistemas dirigido por modelos: a MDA – Model Driven Architecture [OMG 2013]. O funcionamento da MDA pode ser visto como a aplicação de regras de transformação em um modelo-fonte, especificado, por exemplo, no meta-modelo UML (Unified Modeling Language), para obtenção de um modelo-alvo na plataforma destino, por exemplo, Java. Em [Tesoriero et al. 2010], por exemplo, os autores apresentam uma metodologia para desenvolvimento de sistemas ubíquos que agrupa os modelos em três camadas que seguem a especificação da MDA. Outra metodologia dirigida por modelos é apresentada em [Cimino e Marcelloni 2012], que propõe a geração de aplicações multiplataforma baseadas em eventos para diferentes dispositivos móveis. Outro conceito importante relacionado a MDE é a modelagem específica de domínio, do inglês Domain-Specific Modeling (DSM) [Kelly and Tolvanen 2008]. DSM propõe a utilização de modelos específicos mais voltados aos especialistas de domínio, diferentemente de outras abordagens que utilizam modelos genéricos voltadas para os engenheiros de software. DSM emprega o uso sistemático de linguagem de modelagem de domínio específico, do inglês Domain-Specific Modeling Language (DSML). Na área de modelagem educacional, duas abordagens se destacam: as EMLs desenvolvidas prioritariamente para serem utilizadas em práticas educacionais e as linguagens desenvolvidas para outros propósitos e adaptadas para suportarem modelos de atividades de aprendizagem. Em se tratando de EMLs propriamente ditas, o IMS Global Learning Consortium1 criou uma linguagem para tentar estabelecer um padrão em modelagem educacional: a IMS-LD [Koper e Miao 2008]. A IMS-LD considera principalmente os seguintes elementos: os participantes envolvidos na prática educacional (por exemplo, alunos, professor e monitor); as interações e os relacionamentos entre os atores da unidade de aprendizagem; os recursos presentes no ambiente; e os aspectos estritamente pedagógicos, como o progresso nas atividades dos alunos e avaliação de desempenho. Todos esses elementos são integrados em um pacote chamado Unidade de Aprendizagem, do inglês Unit of Learning (UoL). Uma UoL pode ser vista como uma prática de ensino e aprendizagem, por exemplo: uma aula de campo2, um seminário ou uma aula em sala [Zeng 2011]. 3. Objetivos e Contribuições O objetivo principal deste trabalho é propor uma abordagem, baseada na especificação MDA, para construção de sistemas ubíquos aplicados à educação que se beneficie do potencial já comprovado das DSMLs educacionais (como a IMS-LD). Propõe-se que, 1 IMS Global Learning Consortium é uma organização mundial, formada por mais de 190 instituições, com o objetivo principal de promover o avanço das tecnologias na educação. 2 Aulas comuns em Ciências nos quais alunos mapeiam e visitam regiões de interesse 11 através desta abordagem, o especialista de área obtenha ganhos de produtividade e qualidade na elaboração de aulas de campo auxiliadas/mediadas por Computação Ubíqua. A Figura 1 apresenta uma visão geral da abordagem proposta. Figura 1. Visão geral da abordagem proposta Para se alcançar o objetivo estabelecido nesta tese espera-se realizar as seguintes atividades: Elaborar uma abordagem para a construção de aplicações de Ubiquitous Learning que possibilite aos profissionais com pouco ou nenhum conhecimento de programação criar seus próprios aplicativos a partir de representações próximas do seu domínio de conhecimento: MoDULA (Model-Driven Ubiquitous Learning Approach). Criar uma DSML que estenda a EMLs existentes com foco em modelagem de sistemas ubíquos de ensino e aprendizagem, bem como a especificação das sintaxes concreta, abstrata e da semântica da linguagem: a ML4UL (Modeling Language for Ubiquitous Learning). Desenvolver uma ferramenta voltada para o especialista de área, seguindo a abordagem MoDULA, que gerará modelos que poderão ser executados em diferentes plataformas móveis. Estender middlewares existentes que já solucionem desafios do desenvolvimento de sistema ubíquos (e.g., Sensibilidade ao Contexto) e que deem suporte a execução de uma aplicação que interpretará e executará os modelos gerados em múltiplas plataformas: o Player ML4UL. Avaliar a abordagem proposta através da elaboração de um modelo sistemático, disciplinado e controlado baseado em um método qualitativo para analisar a abordagem 12 proposta. A ferramenta desenvolvida será testada com especialistas de diferentes áreas de ensino de graduação em Geociências que irão modelar atividades de aprendizagem e gerarão os aplicativos a partir dos modelos criados. A principal contribuição desse trabalho é a abordagem MoDULA, que possibilita aos especialistas de área a geração de aplicações para atividades de aprendizagem em campo auxiliadas por recursos da computação ubíqua. A MoDULA integra os conceitos de DSM e MDA ao propor a utilização de uma representação inicial voltada para o especialista de área e, posteriormente, aplicar a estrutura de modelos e transformações da MDA (CIM, PIM e PSM) para geração dos sistemas ubíquos. 4. Estado Atual do Trabalho A seguir são descritas as atividades previstas no trabalho que estão em andamento: 1) Revisão bibliográfica. Vários trabalhos nas áreas de Engenharia de Software Dirigida por Modelo, Ubiquitous Learning e Modelagem Educacional já foram levantados, porém esta atividade deve perdurar até a defesa da tese de doutorado. 2) Elaboração da linguagem de modelagem específica para sistemas U-Learning: a ML4UL. A especificação da ML4UL está em andamento e a previsão para conclusão é no segundo semestre de 2013. 3) Criação ou customização de ferramenta para geração dos sistemas U-Learning. Atualmente, está sendo feita uma revisão tanto das ferramentas de modelagem de sistema quanto das de autoria de aplicações educacionais. A partir desse levantamento, uma ferramenta nova deverá ser construída ou uma já existente será adaptada. Espera-se concluir esse levantamento no primeiro semestre de 2013, para ter a primeira versão da ferramenta no final do segundo semestre de 2013. Além dessas atividades também estão previstas neste trabalho de doutorado as seguintes atividades: construção da aplicação para interpretação dos aplicativos gerados nos dispositivos móveis, o player ML4UL; geração de aplicativos e utilização deles em campo; e avaliação da abordagem proposta em todas as suas fases, desde o projeto das atividades de aprendizagem até o uso das aplicações na prática. Mais informações sobre essa avaliação podem ser obtidas na sexta seção. 5. Trabalhos Relacionados Durante a pesquisa bibliográfica foram encontradas várias linguagens e metodologias voltadas para apoiar o desenvolvimento de atividades de aprendizagem para Web ou para sistemas ubíquos de propósito geral. A partir dessa pesquisa realizada, dois trabalhos foram encontrados que tratavam especificamente dos aspectos da modelagem para aplicações em Ubiquitous Learning: [Giemza et al. 2010] e [Malek et al. 2011]. Em [Giemza et al. 2010], os autores apresentam uma ferramenta de autoria, a LEMONADE, para modelagem e geração de aplicativos para dispositivos móveis para serem utilizados em aulas de campo. As aplicações geradas pela ferramenta consistem essencialmente em softwares de anotação (via texto, foto ou áudio) para o sistema operacional Windows Mobile® que seguem um roteiro pré-determinado. Uma das limitações dessa ferramenta é a não previsão de recursos importantes para sistemas ubíquos como adaptação e sensibilidade ao contexto. O fato dela não utilizar linguagens 13 de modelagem diminui sua flexibilidade, não permitindo, por exemplo, a customização para geração de aplicativos em outras plataformas. Contact-Me é uma ferramenta de autoria para modelagem de atividades de aprendizagem que considera o contexto e a adaptabilidade no projeto [Malek et al. 2011]. Ela é baseada na linguagem de modelagem CAAM (Context-aware Adaptive Activities Modeling Language). A ferramenta realiza a transformação do modelo gerado no formato CAAM para o padrão IMS-LD. Para testar as atividades de aprendizagem projetadas, ela possui um ambiente próprio de simulação. Entretanto, a Contact-Me não gera aplicativos a partir dos modelos elaborados. 6. Avaliação dos Resultados Os resultados serão avaliados por meio de um método experimental no qual, após o desenvolvimento da abordagem, serão realizados estudos de caso que observarão os aspectos tanto na usabilidade das ferramentas desenvolvidas quanto na fidelidade dos aplicativos gerados. Será realizado um estudo qualitativo para medir e analisar os resultados obtidos através da abordagem, como os ganhos de produtividade e qualidade na construção de sistemas de U-Learning. Os estudos de caso a serem desenvolvidos terão como área de aplicação aulas de campo de geociências. Estas foram escolhidas por poderem proporcionar a realização de teste de diferentes recursos da computação móvel e ubíqua, tais como: comunicação sem fio, para interação dos alunos entre si e com o professor; GPS, para localização das atividades realizadas; acelerômetro, para medição de ângulos de inclinação das estruturas rochosas; e bússola, para orientação e demarcação de regiões. Referências Bichard, J. & Waern, A. (2008) Pervasive play, immersion and story: designing interference. 3rd international conference on Digital Interactive Media in Entertainment and Arts, ACM, Athens, Greece, 10-17. Cho, H., Gray, J. and Syriani, E. (2012) “Creating visual domain-specific modeling languages from end-user demonstration”. In: Modeling in Software Engineering (MISE), 2012 ICSE Workshop on (pp. 22-28). IEEE. Cimino, M.G.C.A. e Marcelloni, F. (2012). “An efficient model-based methodology for developing device-independent mobile applications”. Em: Journal of Systems Architecture. Vol.58, Ed. 8. pg. 286-304. Setembro, 2012. Figl, K., Derntl, M., Rodriguez, M. C. and Botturi, L. (2010) “Cognitive effectiveness of visual instructional design languages”. In: Journal of Visual Languages & Computing, 21(6), 359-373. Giemza A., Bollen L., Seydel P., Overhagen A. and Hoppe H. U. (2010) LEMONADE: “A Flexible Authoring Tool for Integrated Mobile Learning Scenarios”. In: 6th IEEE International Conference on Wireless, Mobile and Ubiquitous Technologies in Education (WMUTE), 73-80. Huang, Y. M., Chiu, P. S., Liu, T. C. and Chen, T. S. (2011) “The design and implementation of a meaningful learning-based evaluation method for ubiquitous learning”. In: Computers & Education, 57(4), 2291-2302. 14 Lee, H., Lee, W. B. and Kweon, S. C. (2013) “Conjoint analysis for mobile devices for ubiquitous learning in higher education: the korean case”. In: The Turkish Online Journal of Educational Technology, volume 12, issue 1 Koper, R. and Miao, Y. (2008) “Using the IMS LD Standard to Describe Learning Designs”. In: L. Lockyer, S. Bennet, S. Agostinho & B. Harper (Eds.), Handbook of Research on Learning Design and Learning Objects: Issues, Applications and Technologies (pp. 41-86). IDEA group. Malek J., Laroussi M., Derycke A. and Ghezala H. B. (2011) “A Pervasive Learning Design Methodology”. In: The European Journal for the Informatics Professional, Vol. 12, issue 2, Abril. Ogata, H. and YanoY. (2004) “Context-Aware Support for Computer-Supported Ubiquitous Learning”. In: IEEE International Workshop on Wireless and Mobile Technologies in Education (WMTE'04) OMG (2013) MDA specification guide version 1.0.1, Report — omg/03-06-01, 2001. http://www.omg.org/cgi-bin/doc?omg/03-06-01, April. Kelly, S. and Tolvanen, J. P. (2008) “Domain-specific modeling: enabling full code generation”. In: Wiley-IEEE Computer Society Press. Rocha L. (2013) “CAEHV: Um Método para Verificação de Modelos do Tratamento de Exceção Sensível ao Contexto em Sistemas Ubíquos”. Tese de Doutorado apresentada ao programa de Mestrado e Doutorado em Ciência da Computação da Universidade Federal do Ceará. Rocha, L. S., Bosco Ferreira F, J., Lima, F. F., Maia, M. E., Viana, W., de Castro, M. F., & Andrade, R. M. C. (2011). “Ubiquitous Software Engineering: Achievements, Challenges and Beyond”. In Software Engineering (SBES), 2011 25th Brazilian Symposium on (pp. 132-137). IEEE. Spikol, D. e Milrad, M. (2008) Combining Physical Activities and Mobile Games to Promote Novel Learning Practices. Fifth IEEE International Conference on Wireless, Mobile, and Ubiquitous Technology in Education (WMUTE), IEEE, Beijing, 31-38. Tesoriero, R., Gallud, J. A., Lozano, M. D., e Penichet, V. M. R. (2010) “CAUCE: Model-driven Development of Context-aware Applications for Ubiquitous Computing Environments”. Journal of Universal Computer Science, vol. 16, no. 15 (2010), 2111-2138 University of Castilla-La Mancha, Albacete, Spain Wen J., Cheng K., Chen C. and Hsieh Y. (2013) “A study on the application of ubiquitous learning environment to english learning in elementary schools”. In: Universal Journal of Education and General Studies. Vol. 2(2) pp. 053-065. Williams, J., Burton, F., Paige, R. and Polack, F. (2012) “Sensitivity Analysis in ModelDriven Engineering”. Model Driven Engineering Languages and Systems, 743-758. Zeng, M. (2011) “IMS learning design and its application”. In: IEEE International Conference on Multimedia Technology (ICMT), 2011, 5900-5903. 15 Uma abordagem Hı́brida para Geração de Portfólios em Linhas de Produto de Software Jonathas Jivago de Almeida Cruz1 Orientadores: Pedro de Alcântara dos Santos Neto1 , Ricardo de Andrade Lira Rabêlo 2 1 Programa de Pós-Graduação em Ciência da Computação Laboratório de Engenharia de Software e Informática Industrial (EASII) Departamento de Ciência da Computação (DC) Universidade Federal do Piauı́ (UFPI) Teresina, Piauı́, Brasil 2 LABoratory of Intelligent Robotics, Automation and Systems (LABIRAS) Universidade Estadual do Piauı́ Teresina, Piauı́, Brasil {jonathas jivago,pasn}@ufpi.edu.br, ricardor [email protected] Nı́vel: Mestrado Ano de Ingresso: 2012 Previsão da Qualificação: agosto de 2013 Previsão de Conclusão: fevereiro de 2014 Eventos Relacionados: SBES, SBCARS Abstract. Software Product Lines (SPL) is a set of software-intensive systems that share a common, managed set of features satisfying the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way. One of the problems in adopting this approach is the management of Scope Product Portfolio (SPP). The SPP aims to determine which products should be developed and which features they should provide. This paper proposes a hybrid approach that employs Fuzzy Systems and NSGA-II metaheuristic to generate product portfolios based on the SPL assets development costs and the relevance of the features for the target clients. The results have already assessed in a small example and will be assesses again in a bigger study, involving the ArgoUML SPL. Keywords: Software Product Lines, Product Portfolio Scoping, Fuzzy, NSGA-II. 17 1. Caracterização do Problema Linhas de Produto de Software (LPS) é uma abordagem da Engenharia de Software (ES) que permite o desenvolvimento de sistemas de software por meio da reutilização de artefatos. Essa abordagem proporciona vários benefı́cios em termos de redução no custo de desenvolvimento, melhoria na qualidade do software, melhoria na estimação de custos e redução no tempo de lançamento [Pohl et al. 2005][Schmid 2002]. De acordo com [Pohl et al. 2005], o sucesso de uma organização está diretamente relacionado com o gerenciamento de seus produtos, uma vez que, compreende aspectos de desenvolvimento, produção e comercialização de uma linha de produto e suas aplicações. A determinação do tamanho da arquitetura da linha envolve atividades que limitam o sistema pela definição de quais comportamentos devem ou não estar presentes. Essas atividades são conhecidas como escopo [Clements and Northrop 2002]. Existem três tipos de escopo, que são: Escopo do Portfólio de Produtos (EPP), Escopo de Domı́nio (ED) e Escopo de Ativos (EA). O EPP é o tipo de escopo abordado neste trabalho. O EPP tem como objetivo delimitar o conjunto de produtos que devem ser desenvolvidos, assim como, as caracterı́sticas que estes devem prover. Embora as LPS sejam uma abordagem de sucesso, é importante destacar que a adoção dessa abordagem envolve um alto custo em sua fase inicial. As decisões tomadas em suas etapas iniciais influenciam diretamente na lucratividade da linha. Nesse contexto, o planejamento do EPP se configura como uma importante atividade a ser realizada, de forma a auxiliar o gerente a lidar de forma mais adequada com as similaridades e variabilidades presentes na linha. Definir um portfólio considerando tanto aspectos de satisfação do cliente e custos de desenvolvimento dos produtos é um problema NP-Difı́cil [White et al. 2009], sendo portanto, intratável por técnicas tradicionais da ES. Na literatura, encontramos trabalhos que abordam o EPP, mas estes trabalhos focam principalmente em aspectos de lucro [Muller 2011][Gillain et al. 2012]. Ressalta-se que quase nada foi encontrado levandose em consideração o uso técnicas de Inteligência Computacional (IC). Tais técnicas são relevantes para problemas com um grande espaço de busca como o EPP. Conforme as argumentações apresentadas anteriormente e a importância do planejamento do EPP para o sucesso da adoção de LPS, este trabalho de mestrado tem por objetivo propor uma abordagem hı́brida que combina técnicas de IC. Esta abordagem combina Sistemas Fuzzy para determinar o custo de desenvolvimento dos ativos, a qualidade dos produtos gerados e a metaheurı́stica multiobjetiva Non-dominated Sorting Genetic Algorithm (NSGA-II) que é utilizada para buscar os produtos com um custo mı́nimo e com uma maior relevância para os consumidores. As relevância para os produtos são obtidos por meio do uso de Software Quality Function Deployment (SQFD) [Haag et al. 1996]. Pretendemos com o uso dessa abordagem gerar um portfólio contendo os melhores produtos em termos de lucratividade, proporcionando uma maior satisfação aos consumidores. O restante deste artigo está organizado da seguinte forma: na Seção 2 é apresentada a fundamentação teórica que aborda os principais conceitos relacionados a este trabalho; na Seção 3 são detalhadas as contribuições esperadas; na Seção 4 os trabalhos relacionados são descritos; na Seção 5 tem-se a apresentação do estado atual do trabalho; e por fim, na Seção 6 é descrita a metodologia de avaliação dos resultados. 18 2. Fundamentação Teórica 2.1. Linhas de Produto de Software Conforme a definição exposta na Seção 1, uma LPS é uma abordagem de reuso de software que permite o desenvolvimento de sistemas de software por meio do reuso sistemático de artefatos [Pohl et al. 2005]. Organizações que adotam LPS para o desenvolvimento de seus produtos obtém vários ganhos dentre eles [Schmid 2002]: redução no custo de desenvolvimento, no tempo de lançamento, no esforço de manutenção, além de melhorias na qualidade do software e no planejamento. Apesar dos vários benefı́cios providos pelas LPS, alguns problemas ameaçam a adoção dessa abordagem como: o custo inicial necessário para criar uma plataforma reusável e problemas relacionados ao gerenciamento dos produtos linha, dentre eles, destacamos o escopo de portfólio de produtos. 2.2. Sistemas de Inferência Fuzzy Os Sistemas de Inferência Fuzzy (SIF) ou Sistemas Fuzzy (SF) são capazes de lidar com processos altamente complexos, os quais são representados pela imprecisão, incerteza e informações qualitativas. Normalmente, Sistemas de Inferência Fuzzy são baseados em regras linguı́sticas do tipo ”se condição então ação”, no qual a teoria dos conjuntos fuzzy [Zadeh 1965] e a lógica fuzzy [Zadeh 1996] proveem o ferramental matemático necessário para lidar com informações incertas e com regras linguı́sticas. Neste trabalho, utilizamos um SIF do tipo Mamdani [Mamdani 1977] para estimar o custo de desenvolvimento de um ativo. Para isso, usamos como variáveis de entrada o nı́vel de acoplamento entre os ativos, o numero de linhas de código e a complexidade ciclomática. Utilizamos também um outro SIF para estimar a qualidade dos produtos gerados usando o custo de desenvolvimento do produto e o seu nı́vel de satisfação para o cliente como variáveis de entrada. As regras de produção em um SIF tem variáveis linguı́sticas ambos em seus antecedentes e em seus consequentes. Com o uso de SIF do tipo Mamdani é possı́vel representar o conhecimento de um engenheiro de software de maneira totalmente linguı́stica. 2.3. Non-dominated Sorting Genetic Algorithm-II (NSGA-II) O NSGA-II [Deb et al. 2002] é um algoritmo baseado em Algoritmos Genéticos (AG) projetado para resolver problemas multiobjetivos. O NSGA-II inicia gerando uma população inicial P0 de tamanho N , ordenada de acordo com um operador de dominância. Uma segunda população, chamada de Q0 , com o mesmo tamanho de P0 , é gerada aplicando-se os operadores de crossover e mutação sobre P0 . As duas populações são combinadas em uma terceira população chamada R0 , com tamanho 2N . A população R0 é ordenada usando o operador de dominância. Então, uma população P1 é populada com as frentes de Pareto. As frentes de Pareto são geradas usando o operador de distância sobre a população R0 . A população P1 é então usada como a população inicial para a próxima geração do algoritmo. O processo continua até que o critério de parada ser alcançado. 19 2.4. Software Quality Function Deployment (SQFD) O SQFD [Liu 2000] é uma técnica que permite melhorar o desenvolvimento de software por meio da aplicação de técnicas de melhoria de qualidade. O SQFD possui alguns elementos de apoio, dentre os quais se destaca a Matriz de Qualidade. Essa matriz traduz o desejo do cliente em aspectos técnicos e prioriza esses aspectos de acordo com a sua importância. No contexto de uma LPS, os aspectos técnicos são representados pelos ativos do sistema, tais ativos podem ser código fonte, documentos, modelos, etc. Neste trabalho, utilizamos as classes do sistema como aspectos técnicos. Por meio da Matriz de Qualidade consegue-se traduzir a vontade do consumidor, descrita por meio das caracterı́sticas da LPS, em nı́veis de importância dos aspectos técnicos (classes). Por fim, é possı́vel obter a importância de um dado produto com base no conjunto de classes que o compõe. Ressalta-se que a importância dada por um consumidor depende de qual segmento o mesmo está inserido. Desta forma, um mesmo produto poderá ter diferentes nı́veis de relevância dependendo do segmento de mercado. 3. Resultados Esperados e Contribuições De acordo com o exposto na Seção 1, este trabalho propõe uma nova abordagem para resolver um dos problemas de gerenciamento de produtos de uma linha, especificamente, o problema de escopo de portfólio. As principais contribuições de nosso trabalho são descritas a seguir: • A aplicação de um método quantitativo, baseado em questionários, para obter a relevância atribuı́da pelos consumidores às caracterı́sticas do sistema. Destacase que os consumidores são estratificados em grupos, representando assim, os segmentos do mercado; • Uso de um método (SQFD) sistemático para obter o nı́vel de relevância de cada um dos ativos (classes do sistema). Com este método podemos obter a relevância de um produto com base nos nı́veis de importância dado pelos consumidores às caracterı́sticas; • Aplicação de um SIF para estimar o custo de desenvolvimento de um ativo, tendo como entradas métricas utilizadas no desenvolvimento de software; • Uso da metaheurı́stica NSGA-II para buscar produtos, candidatos ao portfólio, que possuam um menor custo de desenvolvimento e com uma maior relevância para os consumidores de um segmento; • Aplicação de um SIF para estimar o melhor produto de cada segmento, utilizando como variáveis de entrada o custo de desenvolvimento de um produto e a sua relevância; • Avaliação dos resultados por meio de um estudo de caso utilizando-se a LPS ArgoUML-SPL1 [Couto et al. 2011] extraı́da do ArgoUML2 . O ArgoUML é uma ferramenta open source amplamente utilizada para projetar sistemas usando UML. 4. Estado Atual do Trabalho A nossa abordagem é composta por cinco etapas: (i) Inferir o custo de desenvolvimento dos ativos; (ii) Calcular a relevância dos ativos para cada segmento; (iii) Calcular os produtos candidatos à pertencer ao portfólio para cada segmento; (iv) Qualificar os produtos 1 2 http://argouml-spl.tigris.org/ http://argouml.tigris.org/ 20 candidatos; (v) Agrupar os melhores produtos de cada segmento. A realização da abordagem será feita por meio da implementação de uma ferramenta desenvolvida em nosso laboratório. Destacamos que desenvolvemos tal ferramenta e avaliamos a geração de portfólios em um trabalho preliminar [Cruz et al. 2013]. A avaliação deste trabalho foi conduzida sobre o sistema JBook-SPL que é uma adaptação do sistema JBook3 para ser uma SPL. Porém, o JBook-SPL é uma LPS com apenas 1 KLOC e que apresenta apenas granularidade no nı́vel de classes entre as caracterı́sticas e os ativos. Até o momento da escrita deste artigo, a nova ferramenta está em fase final de construção, no qual está sendo implementado questões pontuais nas etapas i e ii. Estas questões referem-se a um caráter dinâmico, pois a relevância e o custo de desenvolvimento dos ativos vão ser variáveis. Esse caráter dinâmico existe devido ao ArgoUMLSPL possuir diferentes nı́veis de granularidade entre as caracterı́sticas e os ativos. Esses nı́veis de granularidades são representados por métricas que são geralmente utilizadas para avaliar a implementação de LPS baseadas em pré-processadores. As granularidades podem ser no nı́vel de pacote, classe, interface de método, método, corpo de método, assinatura de método, instrução, atributo e expressão [Couto et al. 2011]. 5. Trabalhos Relacionados Schmid [Schmid 2002] propôs o PuLSE-Eco, uma abordagem que foca em diferentes nı́veis de escopo de uma maneira integrada. Essa abordagem, por sua vez, trata apenas o escopo de domı́nio e escopo do reuso da infraestrutura. Este trabalho, portanto não aborda o escopo de portfólio de produto. O trabalho de Helferich [Helferich et al. 2005] faz uso de técnicas de QFD para fazer o planejamento de portfólio de produtos. O QFD é utilizado para elencar as principais caracterı́sticas dos produtos da linha por meio de questionários, além de identificar os segmentos dos consumidores com base em suas prioridades. Este trabalho não aborda aspectos de custo de desenvolvimento dos produtos. A abordagem proposta por [Muller 2011] visa otimizar o portfólio de produtos em termos de maximização de lucro. Um programa matemático é proposto no qual as variáveis Willingness To Pay (WTP) dos consumidores, custos dos ativos, preços de seus produtos e de concorrentes são considerados. Apesar de ser relatado que os clientes atribuem diferentes valores de importância aos produtos dependendo de seu segmento, tal importância não é considerada na formulação matemática proposta. Uma avaliação empı́rica realizada, releva o impacto para o lucro de cada um dos ativos além de identificar os melhores produtos. 6. Avaliação dos Resultados A avaliação dos resultados será conduzida sobre a LPS ArgoUML-SPL. O ArgoUMLSPL é uma LPS extraı́da da ferramenta ArgoUML, utilizada para o projeto de sistemas usando UML. Ressaltamos que o uso do ArgoUML-SPL para a avaliação e validação dos resultados é encorajado, por ser uma LPS que possui cerca de 120 KLOC, por apresentar 3 http://sourceforge.net/projects/jbookweb/ 21 caracterı́sticas que representam requisitos funcionais e requisitos não-funcionais e por possuir vários nı́veis de granularidade entre as caracterı́sticas e os ativos. Referências Clements, P. and Northrop, L. (2002). Software Product Lines: Practices and Patterns. Addison-Wesley, Secaucus, NJ, USA. Couto, M. V., Valente, M. T., and Figueiredo, E. (2011). Extracting software product lines: A case study using conditional compilation. In Proceedings of the 2011 15th European Conference on Software Maintenance and Reengineering, CSMR ’11, pages 191–200, Washington, DC, USA. IEEE Computer Society. Cruz, J., Neto, P. S., Britto, R., Rabelo, R., and Ayala, W. (2013). Toward a Hybrid Approach to Generate Software Product Line Portfolios. In Proceedings of the IEEE Congress on Evolutionary Computation, page 8, Cancun. Deb, K., Pratap, A., Agarwal, S., and Meyarivan, T. (2002). A fast and elitist multiobjective genetic algorithm: Nsga-ii. Evolutionary Computation, IEEE Transactions on, 6(2):182 –197. Gillain, J., Faulkner, S., Heymans, P., Jureta, I., and Snoeck, M. (2012). Product portfolio scope optimization based on features and goals. In Proceedings of the 16th International Software Product Line Conference on - SPLC ’12 -volume 1, page 161, New York, New York, USA. ACM Press. Haag, S., Raja, M. K., and Schkade, L. L. (1996). Quality function deployment usage in software development. Commun. ACM, 39(1):41–49. Helferich, A., Herzwurm, G., and Schockert, S. (2005). Qfd-ppp: product line portfolio planning using quality function deployment. In Proceedings of the 9th international conference on Software Product Lines, SPLC’05, pages 162–173, Berlin, Heidelberg. Springer-Verlag. Liu, X. (2000). Software quality function deployment. Potentials, IEEE, 19(5):14–16. Mamdani, E. H. (1977). Application of Fuzzy Logic to Approximate Reasoning Using Linguistic Synthesis. IEEE Transactions on Computers, 26(12):1182–1191. Muller, J. (2011). Value-based portfolio optimization for software product lines. In Software Product Line Conference (SPLC), 2011 15th International, pages 15 – 24. Pohl, K., Böckle, G., and Linden, F. J. v. d. (2005). Software Product Line Engineering: Foundations, Principles and Techniques. Springer-Verlag New York, Inc., Secaucus, NJ, USA. Schmid, K. (2002). A comprehensive product line scoping approach and its validation. In Proceedings of the 24th International Conference on Software Engineering, ICSE ’02, pages 593–603, New York, NY, USA. ACM. White, J., Dougherty, B., and Schmidt, D. C. (2009). Selecting highly optimal architectural feature sets with filtered cartesian flattening. J. Syst. Softw., 82(8):1268–1284. Zadeh, L. (1965). Fuzzy Sets*. Information and control, 8(3):338–353. Zadeh, L. A. (1996). Fuzzy logic = computing with words. IEEE Transactions on Fuzzy Systems, 4(2). 22 Título do trabalho: Uma Abordagem Sensível ao Contexto para Visualização em Cenários de Desenvolvimento de Software Nome do aluno: Renan Ribeiro de Vasconcelos Nome do orientador: Cláudia Maria Lima Werner Nível: Mestrado Programa de pós-graduação: Programa de Pós-Graduação em Engenharia de Sistemas de Computação – COPPE – UFRJ Email de contato do aluno: [email protected] Email de contato do orientador: [email protected] Ano de ingresso no programa: 2012 Época prevista de conclusão: Março de 2014 Data da aprovação da proposta de tese/dissertação (qualificação): Julho de 2013 Resumo: O desenvolvimento de software inclui diferentes elementos e características variadas. O conhecimento do contexto de um ambiente de desenvolvimento de software pode revelar informações importantes para um gerenciamento mais eficiente das atividades em diversas situações, como reconhecer um aumento nas requisições de manutenção e na ocorrência de defeitos. Uma forma de ampliar a compreensão do contexto é por meio da aplicação de técnicas de visualização. Este estudo busca apresentar uma abordagem de visualização associada a modelos de contexto para cenários de desenvolvimento de software, apoiando o gerenciamento das atividades de diferentes stakeholders. Palavras-chave: visualização sensível ao contexto; sensibilidade ao contexto; técnicas de visualização; cenário de desenvolvimento de software Sigla(s) do(s) evento(s) do CBSoft relacionado(s): SBES 23 1. Caracterização do Problema Ambientes de desenvolvimento de software envolvem grande quantidade de variáveis, como diferentes atividades, artefatos, papéis etc. Processos com essas características necessitam de atividades de gerenciamento eficazes, porém lidar com essa quantidade de informação pode ser um desafio de alta complexidade. Mecanismos de suporte que colaborem para evidenciar demandas, problemas e melhores práticas a serem seguidas teriam grande apelo para adoção, dando suporte a questões como rastreabilidade de requisitos e atualizando estatísticas de defeitos no produto desenvolvido. Reconhecer prontamente as características atuais do cenário de desenvolvimento de software para, então, viabilizar meios para tratar questões nesse ambiente dinâmico é vital. Caracterizar o contexto de um cenário de desenvolvimento seria uma etapa inicial para analisar dados das tarefas em um projeto de software e derivar conhecimento a partir do progresso atual e lições aprendidas. No entanto, é importante definir qual conjunto de informações é relevante para análise. O gerenciamento do contexto pode oferecer métodos para filtrar o uso de informações em uma determinada situação. Dessa forma, o reúso de conhecimento baseado em projetos de software pode acelerar a tomada de decisões em processos de desenvolvimento [Nunes et al. 2007], como adoção de práticas corretivas e alocação de novos membros em um projeto. A partir do contexto do cenário de desenvolvimento, uma forma de destacar pontos que necessitem de atenção no estado atual seria através de técnicas de visualização. Tais técnicas têm a capacidade de aumentar a percepção com relação ao conteúdo abordado [Schots et al. 2012]. Em conjunto com o contexto apurado em um ambiente, certas técnicas de visualização podem ser utilizadas para fornecer percepção e conhecimento constantes ao longo de um processo de desenvolvimento de software. 2. Fundamentação Teórica Nesta seção serão abordados dois temas que fundamentam o estudo do problema discutido, de forma a viabilizar um tratamento adequado para as questões levantadas. Tais temas são: contexto e visualização em software. 2.1. Contexto em Software Sensibilidade ao contexto é uma característica presente em alguns sistemas e que advém de uma área mais ampla, composta pelos chamados sistemas ubíquos. Aplicações sensíveis ao contexto são conhecidas por sua capacidade de capturar informações do ambiente, incluindo usuários e seus comportamentos, de modo a fornecer respostas personalizadas de acordo com cada estado de contexto [Chen e Kotz 2000]. De forma a derivar ações e tomar decisões a partir do contexto, é importante que tal contexto esteja bem definido e estruturado. Para isso, modelos de contexto passam a ser um ferramental necessário, de modo a padronizar a representação dos elementos. A notação UbiFEX [Fernandes et al. 2011] é uma proposta que segue nessa direção, além de oferecer suporte a diferentes níveis de elementos, como: entidades, relacionadas às dimensões de contexto; informações de contexto, onde cada item colabora na descrição de uma entidade específica; situações, que são compostas por entidades e suas informações com valores definidos; e regras, que permitem associar ações a serem realizadas na ocorrência de uma determinada situação. 24 A partir de uma notação definida, é necessário avaliar os dados que deverão ser incluídos no modelo, ou seja, analisar a pertinência e relevância de informações para compor o modelo de contexto desejado. No âmbito de desenvolvimento de software, Araujo et al. (2004) propõem um conjunto de dimensões que podem ser traduzidas em entidades na notação UbiFEX. De forma a prover informações de contexto para o modelo alvo, que deve abranger características comuns a ambientes de desenvolvimento de software, a proposta de Leite (2011) colabora ao apresentar itens voltando-se para cenários de adaptação de processo, porém aberto a extensões. 2.2. Visualização de Software Buscando por formas de representação de informações de modo intuitivo, técnicas de visualização podem ser aplicadas a software com diferentes focos. Três áreas principais são abordadas em visualização de software: estrutura, referente a partes estáticas e relacionamentos do sistema; comportamento, que explora a execução do sistema com sequência de estados e dados utilizados; e evolução, voltado para o desenvolvimento de software e as mudanças ocorridas ao longo de diferentes etapas [Diehl 2007]. Com um alcance variado, percebe-se que a visualização pode ser utilizada para perspectivas distintas, abrangendo diferentes tarefas realizadas em um ambiente de desenvolvimento de software. Diehl (2007) reconhece que o entendimento de um software pode ser uma atividade complexa e, por isso, técnicas de visualização poderiam colaborar para ampliar o entendimento tanto do software como de seu desenvolvimento. Nesse sentido, tais técnicas representam uma alternativa eficiente para aumentar a percepção nas atividades em que são aplicadas [Schots et al. 2012]. 3. Contribuições Visando prover uma solução de visualização orientada ao contexto em um cenário de desenvolvimento de software, alguns marcos esperados são descritos a seguir. Por buscar-se uma abordagem sensível ao contexto, é importante reconhecer as características relevantes em um ambiente de desenvolvimento. Tais características, ao serem agrupadas em dimensões, compõem um modelo de contexto. Inicialmente, o modelo proposto seria uma extensão do modelo existente em [Leite 2011], que tem o foco para a adaptação de processos. Pretende-se realizar um recorte no modelo, utilizando somente as informações relacionadas a cenários de reutilização de software. Outra etapa necessária na abordagem diz respeito ao uso de técnicas de visualização. A fim de associar técnicas apropriadas a determinadas instâncias de contexto, é importante reunir recomendações de aplicação de técnicas de visualização. Essa lista de recomendações permitiria derivar melhores práticas, dependendo das necessidades colocadas pelo contexto do cenário de desenvolvimento de software. A contribuição nessa perspectiva seria um conjunto de recomendações para visualização sensível ao contexto [Vasconcelos et al. 2013], com respostas a questões como a utilidade de certas visualizações e em que momento sua aplicação seria ideal. A fim de servir como prova de conceito, um protótipo de aplicação reuniria as funcionalidades de importar um modelo de contexto gerado em XMI pela plataforma Odyssey [Odyssey 2013] e gerar visualizações a partir do mesmo. Com um modelo selecionado, seria possível analisar os valores atuais de cada informação de contexto e reconhecer as questões que mereçam atenção. A partir das recomendações de 25 visualização, o protótipo exibiria um conjunto de visualizações adequadas às informações de contexto, de modo a apoiar atividades comuns em cenários de desenvolvimento de software. Esse suporte seria realizado através do reconhecimento de oportunidades de melhoria no contexto, identificando valores inadequados para cada informação do modelo e apresentando visualizações que destaquem esses pontos. De forma a determinar quais visualizações são apropriadas para representar o aspecto que necessite de suporte, é necessário realizar um mapeamento entre cada informação de contexto e recomendações de visualização. Estas recomendações comporiam o conjunto de requisitos para uma representação eficiente da questão em destaque pela informação com valor inadequado. Uma visualização que atenda às recomendações relacionadas para uma informação de contexto torna-se candidata para exibição. A fim de permitir uma customização no mapeamento, uma linha de produtos para visualização sensível ao contexto está sendo proposta. Como uma forma de ilustrar o gerenciamento, a Figura 1 exibe uma transição entre dois estados de um contexto em um cenário de desenvolvimento de software. No momento A, a quantidade de lições aprendidas para iniciar outros projetos é baixa, o que caracteriza pouco conhecimento adquirido no projeto atual, enquanto que o nível de variabilidade de requisições de manutenção também é baixo, o que se traduz em atividades de manutenção mais controladas. Nesse estado, o problema é o reduzido conhecimento obtido. Para esta situação, a fim de dar relevância a tal questão, uma visualização que siga a recomendação de visualização sobre exibir o relacionamento entre itens, no caso entre artefatos utilizados e um determinado domínio, pode ampliar a percepção de informações agregadas em um projeto e a aplicabilidade de componentes, como o gráfico de bolhas agrupando artefatos em categorias. Para o momento B, com conhecimento adquirido sendo alto e nível de variabilidade de manutenções também elevado, uma visualização que apoie atividades de manutenção passa a ser apropriada, como uma técnica para representar a evolução de software, destacando em diagramas de classes as mudanças nas versões de um projeto. Nesse caso, uma visão global do projeto e a utilização de diferentes cores podem colaborar na representação dos tipos de mudanças ocorridas em todas as classes. Com regras bem definidas, que avaliem os dados e determinem o valor de uma informação de contexto, visualizações podem ser exibidas dinamicamente possibilitando uma percepção de problemas em tempo real. Informações relevantes para atividades relacionadas a reúso de software, como as informações de contexto apresentadas na Figura 1, serão utilizadas na composição dessas regras. 4. Estado Atual do Trabalho Com relação ao modelo de contexto, uma proposta inicial foi realizada, baseando-se nas dimensões e informações presentes em [Araujo et al. 2004] e [Leite 2011]. Será tratado um recorte da mesma, selecionando elementos relacionados à reutilização de software. Visando definir um conjunto de recomendações para visualização sensível ao contexto, uma análise de trabalhos em técnicas de visualização foi realizada. O resultado inclui uma lista de recomendações a serem seguidas ao utilizar visões para representar um conjunto de dados. Por exemplo, em visualizações dinâmicas, em que o conjunto de dados é atualizado periodicamente, sugere-se atualizar automaticamente a escala de visualização, pois caso permaneça fixa, a compreensão pode ser prejudicada. 26 Figura 1. Contexto dinâmico De modo a evoluir essa abordagem para a sensibilidade ao contexto, foram feitas associações de aplicação de técnicas de visualização para informações de contexto em dois cenários distintos: um ambiente de desenvolvimento com reutilização de software e um ambiente de desenvolvimento para reutilização. Tais cenários foram escolhidos devido às possibilidades de comparação entre as instâncias de contexto, uma vez que em um cenário o desenvolvimento de sistemas apenas reutiliza artefatos, enquanto no outro o desenvolvimento visa criar componentes voltados para reúso em futuros projetos. 5. Comparação com Trabalhos Relacionados Além deste trabalho, alguns estudos baseiam-se em técnicas de visualização para enriquecer a percepção em ambientes de desenvolvimento de software. Algumas abordagens se voltam para análises em workspaces de projetos, de modo a possibilitar um acompanhamento de mudanças feitas durante a codificação. Nessa linha, Scamp [Lanza et al. 2010] é uma ferramenta que permite inspeções dinâmicas, analisando mudanças no código e exibindo visualizações personalizadas. Métricas extraídas durante a execução de processos de software também podem ser usadas para otimizar o gerenciamento das atividades, informando sobre a saúde e a trajetória de um projeto através de visualizações. O framework PIVoT [Sharma e Kaulgud 2012] coleta e analisa dados em ambientes heterogêneos de projetos. Outro grupo de abordagens é voltado para interações entre usuários, artefatos e dados provenientes do processo de desenvolvimento. Sarma et al. (2009) apresentam a plataforma visual Tesseract, que analisa relacionamentos entre artefatos, desenvolvedores, defeitos e registros de comunicação, incluindo informações de redes sociais a fim de entender o comportamento da equipe de desenvolvedores. É importante ressaltar que nenhum desses estudos utiliza como base um conjunto de recomendações para relacionar contextos de cenários de desenvolvimento com as visualizações a serem aplicadas. Este trabalho pretende abordar essa questão, de forma a aumentar a percepção do contexto de desenvolvimento e possibilitar o desempenho mais eficiente de todas as atividades relacionadas. 27 6. Avaliação dos Resultados A avaliação da proposta seria concentrada no protótipo desenvolvido. A partir de dados simulados para cenários hipotéticos, seria possível acompanhar a alteração das visualizações conforme mudanças ocorram no contexto dos cenários. Uma forma de confirmar a aplicação da proposta seria através de um experimento, a fim de verificar se as visualizações orientadas ao contexto apresentadas dinamicamente colaboram para uma melhor compreensão do cenário. A interpretação das visualizações, reconhecendo a questão em destaque em determinado momento no cenário, é o principal aspecto da avaliação. Para avaliar a eficiência, serão analisadas métricas como o tempo gasto para identificar e interpretar as informações visuais. Referências Araujo, R.M., Santoro, F. M., Brézillon, P. Borges, M.R.S., Rosa, M.G.P. (2004). Context Models for Managing Collaborative Software Development Knowledge. In International Workshop on Modeling and Retrieval of Context (MRC), Ulm, Germany, pp. 61-72. Chen, G., Kotz, D. (2000). A Survey of Context-Aware Mobile Computing Research. Dartmouth College Technical Report TR2000-381. Diehl, S. (2007), Software Visualization: Visualizing the Structure, Behaviour, and Evolution of Software, Springer, 1st edition. Lanza, M., Hattori, L., Guzzi, A. (2010). Supporting collaboration awareness with realtime visualization of development activity. In 14th European Conference on Software Maintenance and Reengineering (CSMR), Madrid, Spain, pp. 207-216. Leite, A.M.S. (2011). Modelo de Contexto para Adaptação de Processo de Software, Dissertação de M.Sc., UNIRIO, Rio de Janeiro, Brazil. Nunes, V.T., Santoro, F.M., Borges, M.R.S. (2007). Um modelo para gestão de conhecimento baseado em contexto. In XXVII Simpósio Brasileiro de Sistemas Colaborativos (SBSC), Rio de Janeiro, Brazil, pp. 69-82. Odyssey. (2013) “Projeto Odyssey”, http://reuse.cos.ufrj.br/odyssey, Junho. Sarma, A., Maccherone, L., Wagstrom, P., Herbsleb, J.D. (2009). Tesseract: Interactive Visual Exploration of Socio-Technical Relationships in Software Development. In 31st International Conference on Software Engineering (ICSE), Vancouver, Canada, pp. 23-33. Schots, M., Werner, C., Mendonça, M. (2012). Awareness and Comprehension in Software/Systems Engineering Practice and Education: Trends and Research Directions. In XXVI SBES (Grand Challenges Track), Natal, Brazil, pp. 186-190. Sharma, V.S., Kaulgud, V. (2012). PIVoT: Project Insights and Visualization Toolkit. In 3rd International Workshop on Emerging Trends in Software Metrics (WETSoM), pp. 63–69. Vasconcelos, R.R., Schots, M., Werner, C. (2013). Recommendations for ContextAware Visualizations in Software Development. In X Workshop de Manutenção de Software Moderna (WMSWM), XII SBQS, Salvador, Brasil. 28 P ROGRAMA DE P ÓS -G RADUAÇ ÃO EM C I ÊNCIA DA C OMPUTAÇ ÃO U NIVERSIDADE F EDERAL DE C AMPINA G RANDE A PRIMORANDO A VERIFICAÇ ÃO DE CONFORMIDADE EM PROGRAMAS UTILIZANDO A METODOLOGIA D ESIGN BY C ONTRACT M ESTRANDO A LYSSON F ILGUEIRA M ILANEZ [email protected] Ingresso em 2012, conclusão prevista para Junho/2014. Proposta aprovada em 21 de Fevereiro de 2013. O RIENTADORES T IAGO M ASSONI , ROHIT G HEYI {massoni, rohit}@dsc.ufcg.edu.br Resumo. No contexto de Design By Contract, verificação de conformidade entre código e especificação vem ganhando maior interesse, dada a necessidade de prover maior qualidade ao cliente. As não–conformidades que estejam presentes em sistemas formalmente especificados devem ser detectadas o quanto antes, para manter a qualidade do sistema. Existem tanto soluções dinâmicas quanto estáticas para a verificação de não-conformidades em código Java anotado com JML (Java Modeling Language), uma instância da programação baseada em contratos. Contudo essas soluções não apresentam qualquer facilidade para a categorização das não-conformidades detectadas; essa tarefa é realizada manualmente demandando bastante tempo e esforço por parte do programador. Com um mecanismo que torne essa atividade ao menos semiautomática estaremos contribuindo para o desenvolvimento de sistemas que utilizem programação por contratos como forma de aprimorar o projeto dos programas, e por consequência, sua qualidade geral. O presente trabalho de Mestrado tem como objetivos o aprimoramento do método baseado em análise dinâmica concretizado pela ferramenta JMLOK, adicionando-lhe um módulo para a categorização das não-conformidades detectadas e o relato de estudos de caso e experimentos avaliando o potencial desta ferramenta e de seu método de aplicação. Palavras–chave: programação por contratos, conformidade, categorização. SBES 29 1. Caracterização do Problema No contexto de verificação baseada em contratos, as não-conformidades existentes entre o código e sua especificação formal devem ser detectadas o quanto antes, para que a qualidade do sistema seja mantida e assegurada. Contudo as soluções atualmente existentes (tanto dinâmicas quanto estáticas) não apresentam qualquer facilidade para a classificação dessas não-conformidades; sendo essa tarefa realizada manualmente pelo programador, demandando bastante tempo e esforço. Com um mecanismo que (semi) automaticamente categorize as não–conformidades essa tarefa se tornará mais prática. 2. Fundamentação Teórica 2.1. Design by Contract A ideia fundamental do Design by Contract (DBC) [Meyer 1992a] é que um módulo cliente (que dependa de determinada funcionalidade(s) de outro(s) módulo(s)) e um fornecedor (cuja funcionalidade seja utilizada por outro(s) módulo(s)) têm um contrato entre si estabelecendo direitos e obrigações de cada módulo. Dessa forma o módulo cliente, antes da chamada de um módulo fornecedor, deve garantir propriedades relacionadas aos parâmetros de entrada desse fornecedor (as pré-condições dos métodos); o módulo fornecedor por sua vez, deve garantir propriedades relacionadas ao resultado da sua execução com os dados do cliente (as pós-condições dos métodos). Uma das primeiras implementações conhecidas para linguagens Orientadas a Objeto (O.O.) de DBC foi implementada em Eiffel [Meyer 1992b]. Atualmente, a metodologia é empregada para várias linguagens (Java [Leavens et al. 1999], C# [Barnett et al. 2004], dentre outras). Uma grande vantagem de DBC é que, dado que pré e pós-condições sejam especificadas no código de modo que possam ser verificadas por um compilador, qualquer violação do contrato entre o módulo cliente e o fornecedor pode ser detectada imediatamente, permitindo a construção de sistemas mais confiáveis e de maior qualidade. 2.2. Conformidade No contexto da verificação dos contratos surge o conceito de conformidade [Cheon 2007]: o código satisfaz a sua especificação. No Listing 1 é apresentado um trecho de código que satisfaz sua especificação. Já não-conformidade é um código que não satisfaz a sua especificação; conforme apresentado posteriormente no Listing 2. Os casos nos quais não ocorre conformidade entre código e especificação são: 1. Quando o cliente garante as pré-condições e o fornecedor não garante as póscondições - uma violação do contrato por parte do fornecedor; 2. Quando o cliente não garante as pré-condições do fornecedor - neste caso uma violação do contrato por parte do cliente. Listing 1. Exemplo do uso de DBC c l a s s Example { int x = 0; requires n > 0; e n s u r e s x >= n ; void setX ( i n t n ){ x = x + n ; } } 30 No contexto do desenvolvimento de programas Java seguindo a metodologia DBC, pode ser utilizada a Java Modeling Language (JML) [Leavens and Cheon 2006]. Em JML, o comportamento das classes e interfaces Java é especificado com o uso de asserções tais como pré-condições, pós-condições e invariantes. Estas asserções podem ser utilizadas para verificar se o código está em conformidade com sua especificação (se os contratos entre as classes/interfaces estão sendo respeitados), aumentando a confiabilidade na qualidade do programa. No Listing 2 é apresentado um trecho de código de um sistema que é especificado em JML. O sistema possui como um de seus componentes uma classe do tipo GenerationCounter que possui 3 métodos: updateCount que atualiza o número de gerações se o seu parâmetro receber o valor true (indicando a criação de uma geração), resetCount que reinicia o contador de gerações, e o construtor da classe. Essa classe possui um invariante - claúsula invariant de que o número de gerações estará no intervalo [0,MAX]. Listing 2. Exemplo de DBC em JML public class GenerationCounter { f i n a l s t a t i c p u b l i c i n t MAX = 4 ; / /@ i n v a r i a n t 0 <= c o u n t G e n e r a t i o n s && c o u n t G e n e r a t i o n s <= MAX; p r i v a t e / ∗@ s p e c p u b l i c @∗ / i n t c o u n t G e n e r a t i o n s ; public GenerationCounter ( ) { this . countGenerations = 1; } / /@ e n s u r e s ( b== t r u e )==>( t h i s . c o u n t G e n e r a t i o n s == \ o l d ( t h i s . c o u n t G e n e r a t i o n s + 1 ) ) ; public void updateCount ( boolean b ){ i f ( b ) { t h i s . c o u n t G e n e r a t i o n s ++; } } / /@ e n s u r e s t h i s . c o u n t G e n e r a t i o n s == 0 ; public void r e s e t C o u n t ( ) { this . countGenerations = 0; } } Contudo, o código Java anterior não está em conformidade com sua especificação JML. Considere a sequência de chamadas que seguem: G e n e r a t i o n C o u n t e r g = new G e n e r a t i o n C o u n t e r ( ) ; g . resetCount ( ) ; g . updateCount ( true ) ; g . updateCount ( true ) ; g . updateCount ( f a l s e ) ; g . updateCount ( true ) ; g . updateCount ( f a l s e ) ; g . updateCount ( true ) ; g . updateCount ( f a l s e ) ; g . u p d a t e C o u n t ( t r u e ) ; / / O i n v a r i a n t e da c l a s s e G e n e r a t i o n C o u n t e r é v i o l a d o . Após cinco chamadas ao método updateCount com true como parâmetro, o invariante será violado. Este problema de não-conformidade só é evidenciado por meio de chamadas sucessivas ao método updateCount num único caso de teste. O exemplo é pequeno, e tal erro possivelmente seria detectado pelo desenvolvedor. Porém, em sistemas reais, não-conformidades mais sutis podem ser de difı́cil identificação, tornando de grande valia o uso de ferramentas automáticas para testes de verificação de conformidade. 3. Trabalhos Relacionados As principais formas existentes para verificação de conformidade entre código-fonte e especificação são: manualmente por meio da definição de leis para prova formal da conformidade, conforme apresentado no trabalho de Freitas [Freitas 2009]; 31 com o uso de ferramentas para checagem estática das especificações (como o ESC/Java [Flanagan et al. 2002]); e, de forma dinâmica com o uso de testes de unidade para checar conformidade entre o código e sua especificação. As ferramentas para verificar conformidade entre código Java e especificação JML de modo dinâmico diferem basicamente no processo utilizado para a geração dos dados de teste; quanto ao processo de geração de casos de teste, este é realizado de modo aleatório. A seguir serão apresentadas as formas de geração de dados de teste para as ferramentas: JMLUnit [Cheon and Leavens 2002], JMLUnitNG [Zimmerman and Nagmoti 2011], JET [Cheon and Rubio-Medrano 2007] e JMLOK [Varjão et al. 2011]. A ferramenta JMLUnit, foi uma das primeiras ferramentas para verificação de conformidade entre código Java e especificação JML. Ela realiza a geração dos dados de teste para tipos primitivos Java por meio de chamadas aos métodos sob teste combinando valores para seus parâmetros de entrada. Na ferramenta JMLUnitNG, que foi uma evolução da ferramenta JMLUnit, os dados de teste são gerados com o uso de Java reflection. Na ferramenta JET há a utilização de algoritmos genéticos para a geração dos dados de teste. Por fim, na ferramenta JMLOK a geração dos dados de teste é realizada de modo completamente automático e aleatório. 4. Estado Atual do Trabalho Apesar da grande utilidade das ferramentas (apresentadas na Seção 3) na identificação das não-conformidades entre código Java e especificação JML, elas ainda não dão suporte à categorização automática dessas não-conformidades; no exemplo apresentado no Listing 2, as ferramentas poderiam identificar que há uma não-conformidade entre o código e sua especificação (não é possı́vel afirmar se o erro é advindo da especificação ou do código-fonte; mas pretendemos ajudar a apontar a causa do erro) e reportariam que houve um erro de um determinado tipo de JML; contudo não forneceriam ao programador qualquer outra informação que o auxiliasse a depurar o problema ocorrido. Essas ferramentas fornecem apenas informações relacionadas à linha do código, o nome do método e da classe onde a não-conformidade foi detectada. Todo o processo de categorização é realizado manualmente: o programador, de posse das informações de onde foi detectada a não-conformidade, vai ao código-fonte, inspeciona o trecho de código onde foi detectado o problema e o categoriza de acordo com seu impacto no programa. Visando tornar esse processo mais prático, recentemente propusemos um modelo para a classificação de não-conformidades, com suas causas prováveis. As categorias e suas causas são: • invariant error - quando a não-conformidade é causada por uma pré-condição fraca ou um invariante forte ou um null-related (um atributo que não foi inicializado ou que recebe o valor null); • precondition error - quando se trata de uma não-conformidade JMLInternalPreconditionError (quando a violação da pré-condição ocorre no corpo de um método, não tendo sido causada por um dado de entrada criado automaticamente pela ferramenta de teste que viola a pré-condição de um determinado método) e é causada por uma pré-condição forte ou uma pós-condição fraca; • postcondition error - quando causada por uma pré-condição fraca ou uma póscondição forte; 32 • evaluation error - quando há o lançamento de uma exceção que torna inválida uma expressão a ser avaliada numa pré- ou pós-condição ou invariante; • constraint error - quando ocasionada por uma restrição histórica forte ou uma pré-condição fraca ou um null-related. Essa falta de uma abordagem mais detalhada para auxiliar na categorização das não-conformidades ficou evidente durante os experimentos que realizamos com a ferramenta JMLOK em mais de 29 KLOC e mais de 9 K linhas de especificação JML (que chamamos de KLJML) consistindo de programas-exemplo (Samples) disponı́veis no repositório JML1 e programas reais: Bomber, JAccouting, JSpider [Rebêlo et al. 2009], HealthCard [Rodrigues 2009], Mondex [Tonin 2007] e TransactedMemory [Poll et al. 2002] disponı́veis na literatura; e detectamos 79 não-conformidades. As não-conformidades detectadas foram categorizadas segundo o nosso modelo e reportadas aos autores das unidades experimentais; os autores nos reportaram que estão de acordo com nossa categorização. Realizamos também um experimento com a ferramenta JET englobando mais de 6 KLOC e mais de 5 KLJML com as unidades experimentais: Samples, JAccounting, Mondex e TransactedMemory; e detectamos 9 não-conformidades; além disso fizemos uma comparação estatı́stica entre as ferramentas para determinar qual apresentava melhor desempenho em relação ao número de não-conformidades detectadas e a cobertura dos testes gerados (cobertura considerando cobertura de statements Java e JML) e obtivemos por meio de testes de Wilcoxon Signed-Rank que a ferramenta JMLOK apresenta melhor desempenho com 95% de confiança. Com estes experimentos pudemos verificar que as ferramentas existentes apenas relatam o tipo de erro que ocorreu na execução de determinado caso de teste, não auxiliando o programador a descobrir se os erros advém das mesmas falhas. Assim, a parte de depuração dos erros reportados fica a cargo de uma atividade manual do programador verificar o código-fonte do método no qual o erro fora encontrado e checar se os demais erros são advindos de uma mesma falha. 5. Contribuições Os principais objetivos do presente trabalho são auxiliar no processo de categorização de não-conformidades detectadas entre código-fonte Java e especificação JML, por meio do aprimoramento da ferramenta JMLOK adicionando-lhe um módulo para realizar a categorização das não-conformidades detectadas; a realização de experimentos comparando o total de coincidências entre a categorização manual (realizada por um especialista seguindo o modelo proposto) e a categorização automática dividido pelo total de não-conformidades detectadas, e a realização de estudos de caso para avaliar a eficácia do método de categorização proposto. Entendemos que isso é essencial para identificar pontos fracos na nossa proposta e justificar melhor os pontos fortes. O feedback gerado por estes estudos servirá para ajustar os resultados e o suporte ferramental antes do final do projeto de Mestrado. Como objetivos secundários temos a modularização da ferramenta e a realização de melhorias no processo utilizado para geração de testes. Com isso, estaremos contribuindo para o desenvolvimento de sistemas que utilizem programação por contratos como forma de aprimorar o projeto dos programas, e por consequência, sua qualidade geral. 1 http://www.eecs.ucf.edu/ leavens/JML/examples.shtml 33 Referências Barnett, M., Leino, K. R. M., and Schulte, W. (2004). The Spec# Programming System: An Overview. pages 49–69. Springer. Cheon, Y. (2007). Automated Random Testing to Detect Specification-Code Inconsistencies. In Karras, D. A., Wei, D., and Zendulka, J., editors, SETP, pages 112–119. ISRST. Cheon, Y. and Leavens, G. T. (2002). A Simple and Practical Approach to Unit Testing: The JML and JUnit Way. In ECOOP 2002, volume 2374 of LNCS, pages 231–255. Springer. Cheon, Y. and Rubio-Medrano, C. E. (2007). Random test data generation for Java classes annotated with JML specifications. In In International Conference on Software Engineering Research and Practice, Volume II, June 25–28, 2007, Las Vegas, pages 385–392. Flanagan, C., Leino, K. R. M., Lillibridge, M., Nelson, G., Saxe, J. B., and Stata, R. (2002). Extended static checking for Java. In Proceedings of the ACM SIGPLAN 2002 Conference on Programming language design and implementation, PLDI ’02, pages 234–245, New York, NY, USA. ACM. Freitas, G. R. F. (2009). Refactoring Annotated Java Programs: A Rule-Based Approach. Master’s thesis, Universidade de Pernambuco. Leavens, G. T., Baker, A. L., and Ruby, C. (1999). JML: A Notation for Detailed Design. Behavioral Specifications of Businesses and Systems, pages 175–188. Leavens, G. T. and Cheon, Y. (2006). Design by Contract with JML. Meyer, B. (1992a). Design by Contract. In Advances in object-oriented software engineering, Prentice Hall object-oriented series, pages 1–50. Prentice Hall. Meyer, B. (1992b). Eiffel: the language. Prentice-Hall, Inc., Upper Saddle River, NJ, USA. Poll, E., Hartel, P., and Jong, E. (2002). A Java Reference Model of Transacted for Smart Cards. In CARDIS, pages 75–86. Rebêlo, H., Lima, R., Cornélio, M. L., Leavens, G. T., Mota, A. C., and Oliveira, C. (2009). Optimizing JML Features Compilation in Ajmlc Using Aspect-Oriented Refactorings. In SBLP, pages 117 – 130. Rodrigues, R. M. S. (2009). JML-Based Formal Development of a Java Card Application for Managing Medical Appointments. Master’s thesis, Universidade da Madeira. Tonin, I. (2007). Verifying the Mondex Case Study: the KeY approach. Technical report. Varjão, C., Gheyi, R., Massoni, T., and Soares, G. (2011). JMLOK: Uma Ferramenta para Verificar Conformidade em Programas Java/JML. In CBSoft’ 11: 2nd Brazilian Conference on Software: Theory and Practice (Tools session). Zimmerman, D. M. and Nagmoti, R. (2011). JMLUnit: the next generation. In Proceedings of the 2010 international conference on Formal verification of object-oriented software, FoVeOOS’10, pages 183–197, Berlin, Heidelberg. Springer-Verlag. 34 Configuração de Produtos em Linha de Produtos de Software Juliana Alves Pereira, Eduardo Figueiredo Programa de Pós-Graduação em Ciências da Computação (PPGCC) Laboratório de Engenharia de Software (LabSoft), Departamento de Ciência da Computação (DCC), Universidade Federal do Minas Gerais (UFMG) Belo Horizonte - MG – Brasil {juliana.pereira, figueiredo}@dcc.ufmg.br Resumo. Para melhorar a qualidade do software e reduzir os custos e prazos, muitas empresas estão adotando a abordagem de Linha de Produtos de Software (LPS). Um processo chave em LPS é a configuração de produtos, que é o processo de customização dos principais ativos de uma LPS. A fim de apoiar as empresas durante estas customizações, métodos e ferramentas de gerência de variabilidade e configuração de produtos têm sido desenvolvidos. Entretanto, através de um estudo exploratório foi identificado que os métodos e ferramentas existentes não são suficientes. Orientação e apoio são necessários para aumentar a eficiência das empresas ao lidar com milhares de combinações de ativos possíveis em uma LPS. Neste trabalho propomos um modelo, baseada em técnicas de busca e otimização, para apoiar as empresas na configuração semi-automática de produtos. O principal objetivo deste modelo é maximizar a satisfação de clientes e auxiliar empresas desenvolvedoras de LPS, em busca da configuração do produto que traga melhor custo-benefício para o cliente. O modelo proposto está sendo automatizado por uma ferramenta e avaliado em estudos experimentais. Palavras-Chave: Linha de Produtos de Software, Gerência de Variabilidade, Configuração de Produtos. 1. Introdução A crescente necessidade de desenvolvimento de sistemas de software maiores e mais complexos exige um melhor suporte para artefatos reutilizáveis [7]. Muitas técnicas, como Linha de Produtos de Software (LPS), têm sido propostas para oferecer avançado suporte a reutilização de software [10]. LPS explora o fato de sistemas em um mesmo domínio serem semelhantes e terem potencial para reutilização [7]. Considerando que tem se tornando comum a comercialização de produtos que se diferenciam por variações em suas características, grandes empresas tais como: Boeing, Hewlett Packard, Nokia e Siemens; têm investido em LPS [8]. LPS permite às empresas rápida entrada no mercado por fornecer capacidade de reutilização em larga escala com customização em massa [6]. Com esse enfoque, promete-se obter ganhos na produtividade, produtos mais confiáveis e preço mais acessível [4]. Esses fatores contribuem para um aumento significativo na satisfação do cliente. Um elemento de fundamental problema em LPS corresponde ao tamanho das LPS industriais. LPS industriais podem facilmente incorporar milhões de características variáveis. A complexidade causada por essa quantidade de variabilidade torna o 35 gerenciamento de variabilidade e as tarefas de derivação de produtos extremamente difícil [4]. A fim de apoiar as empresas na gerência de variabilidade e configuração de produtos, novos métodos e ferramentas têm sido desenvolvidos [10]. Entretanto, através de um estudo exploratório foi identificado que os métodos e ferramentas existentes não são suficientes para apoiar as empresas durante a configuração de produtos. Orientação e apoio são necessários para aumentar a eficiência das empresas ao lidar com milhares de combinações possíveis em uma LPS. A configuração de produtos em LPS é uma tarefa cuja complexidade aumenta exponencialmente à medida que aumenta o número de características envolvidas e restrições a serem considerada [7]. Para abordar este problema, apresentamos um modelo para otimizar a variabilidade fornecida em LPS. O restante do artigo está organizado da seguinte forma. A Seção 2 introduz os conceitos fundamentais de variabilidade em LPS. Na Seção 3 são detalhadas as contribuições deste trabalho. A Seção 4 apresenta métodos e ferramentas disponíveis para gerência de variabilidade e configuração de produtos em LPS. A Seção 5 descreve o problema e o modelo proposto. A Seção 6 descreve o estado atual do trabalho. Por fim, os trabalhos relacionados são discutidos na Seção 7. 2. Variabilidade em LPS A variabilidade em uma LPS é dada pela seleção de componentes específicos que adicionam uma ou mais características aos produtos [6]. Características comuns a um domínio formam o núcleo e outras características definem pontos de variação [7]. Uma vez que o domínio do sistema é decomposto em características independentes e facilmente combináveis, diferentes versões de um sistema são possíveis mediante a inclusão ou exclusão por combinação de determinadas características [4]. Por exemplo, os automóveis de um mesmo modelo se diferenciam por itens como airbag e som. Existem características comuns a todos os produtos e outras características podem variar de um produto para outro. Entretanto, um desafio predominante em LPS é gerenciar a variabilidade e prover ao cliente uma configuração de produto com melhor custo-benefício. LPS industriais podem facilmente incorporar milhares de produtos, devido à evolução contínua da LPS, resultando em uma explosão combinatória de variantes [4]. Por exemplo, a partir de uma LPS que oferece apenas 20 características variáveis, é teoricamente possível derivar 1.048.576 produtos. Este simples exemplo mostra que, mesmo um pequeno número de características variáveis resulta numa explosão combinatória de variantes. 3. Contribuições Este trabalho tem como principais contribuições um estudo exploratório de métodos e ferramentas existentes que dão apoio ao gerenciamento de variabilidades em LPS. Este estudo permitiu: comparar funcionalidades oferecidas pelas ferramentas, identificar redundâncias e funcionalidades recorrentes em abordagens para LPS, e destacar melhorias que possam ser realizadas em ferramentas existentes. Baseando-se neste estudo, um modelo para apoiar as empresas na configuração semi-automática de produtos é proposto. Este modelo considera aspectos como (i) preço de desenvolvimento das características para a empresa desenvolvedora da LPS; (ii) orçamento que o cliente possui para aquisição do software; e (iii) grau de importância das características para o cliente. O principal objetivo é apoiar as empresas durante a 36 otimização da configuração das características, em busca da configuração de produto com melhor custo-benefício para o cliente. 4. Métodos e Ferramentas para Gerenciamento de LPS Métodos e ferramentas, tais como, SPLOT1, FeatureIDE2, XFeature3, fmp4 e pure::variants5 são utilizados para apoiar a gerência de variabilidade e configuração de produtos em LPS. Grandes empresas de software estão adotam estas ferramentas para desenvolver seus produtos [8][10]. Devido à quantidade de métodos e ferramentas disponíveis, este trabalho realiza um estudo para identificar diferenças, redundâncias e limitações destas ferramentas. Inicialmente realizamos um estudo exploratório utilizando as ferramentas SPLOT [5] e FeatureIDE [11]. Este estudo inicial envolveu 56 estudantes que realizaram um curso avançado em Engenharia de Software no ano de 2012. Pedimos aos participantes para executar três tarefas usando SPLOT ou FeatureIDE. As tarefas incluem o uso de funcionalidades para (i) criar e editar um modelo de características; (ii) analisar automaticamente o modelo de características criado e observar as estatísticas provida pela ferramenta; e (iii) configurar um produto usando a funcionalidade de configuração de produtos. Finalmente, pedimos aos participantes para responderem duas perguntas simples sobre o que eles gostaram e o que não gostaram na ferramenta utilizada. Em particular, o ponto que chamou a atenção foi à dificuldade e a falta de auxílio destas ferramentas durante a configuração de produtos. Aproximadamente 70% dos participantes realizaram algum comentário sobre isso. A partir desta observação, propomos um modelo que está sendo implementado como uma extensão da ferramenta FeatureIDE. Além de ser bastante utilizado, FeatureIDE foi escolhido por sua capacidade de suportar técnicas modernas de programação, tais como programação orientada a aspectos [3] e programação orientada a características [1]. Adicionalmente, a ferramenta está integrada a várias técnicas de composição, tais como AHEAD, FeatureHouse, Feature C++, AspectJ, Antenna e CIDE. 5. Modelo Computacional Proposto À medida que o tamanho e a complexidade dos sistemas aumentam, surge a necessidade da adoção de um paradigma de desenvolvimento baseado em LPS. Entretanto, conforme estudo apresentado anteriormente, apesar de diversas ferramentas apoiarem a configuração de produtos, nenhuma das ferramentas avaliadas oferece um método de customização de produtos para apoiar as empresas durante a configuração e recomendação de produtos ao cliente. Como solução, este trabalho propõe um modelo de configuração de produtos em LPS que satisfaça restrições impostas por clientes que irão adquirir o produto. Como representado pela Figura 1, o método proposto prevê que o produto seja negociado em função das características da linha e do orçamento disponível pelo cliente. Assim, o 1 http://www.splot-research.org/ http://wwwiti.cs.uni-magdeburg.de/iti_db/research/featureide/ 3 http://www.pnp-software.com/XFeature/ 4 http://gsd.uwaterloo.ca/fmp/ 5 http://www.pure-systems.com/ 2 37 objetivo é otimizar a configuração de características e apoiar as empresas na configuração de produtos que maximizem a satisfação dos clientes. Figura 1 Modelo para apoiar a configuração de produtos em LPS As principais constantes definidas pelo modelo do problema são: (i) o limite de orçamento que o cliente possui para aquisição do software (O ∈ Reais); (ii) o grau de importância da característica i para o cliente (G1..n ∈ [0, 1]); (iii) o preço em adicionar a característica i ao produto a ser entregue ao cliente (P1..n ∈ Reais); e (iv) a expressão proposicional na forma normal conjuntiva derivada a partir da árvore modelada (E(C)). Onde, C(n) ∈ Naturais representa a quantidade de características presentes no modelo e Ci ∈ {0, 1} representa a não inclusão ou inclusão da característica i no produto configurado. Adicionalmente, todas as restrições definidas pelo modelo devem ser satisfeitas. n A função objetivo é maximizar z(n) = ∑ GiCi . i =1 n Sujeito a: ∑ PiCi ≤ O , satisfazendo E(C). i =1 Este modelo foi implementado utilizando técnicas de busca e otimização. Inicialmente utilizamos algoritmos de enumeração exaustiva com pré-processamento e backtracking [2]. Devido à natureza NP-Completo [2] deste problema, à medida que a instância do problema cresce, estes algoritmos passam a exigir muitos recursos computacionais (essencialmente, tempo de processamento) para encontrar a solução ótima. Portanto, é proposta a utilização de um algoritmo guloso de busca, baseado em heurísticas, para encontrar soluções suficientemente boas em um menor horizonte de tempo. Este modelo proporciona uma maior satisfação aos clientes que poderão adquirir produtos que atendam especificamente as suas necessidades. 6. Estado Atual do Trabalho Além do custo-benefício do produto para o cliente, o modelo está sendo alterado para considerar as dificuldades de desenvolvimento e manutenção do produto para a organização desenvolvedora da LPS. A organização desenvolvedora tem interesse em (i) minimizar o esforço de desenvolvimento e integração de características para compor um produto e (ii) gerenciar um conjunto reduzido de versões de produtos da LPS. Para ilustrar, considere que dentre os possíveis produtos que satisfaça o cliente, um deles já se encontra instanciado e configurado. Neste caso, o produto será selecionado para 38 satisfazer os interesses da organização desenvolvedora, por exemplo, os custos em testes não serão necessários para este novo cliente. O modelo proposto foi inicialmente avaliado para pequenas LPS, está sendo automatizado por uma ferramenta e sua eficácia será demonstrada através de um estudo de caso para otimizar a variabilidade em grandes LPS industriais. 7. Trabalhos Relacionados A abordagem proposta por Sewerjuk [9] examina possibilidades e consequências na introdução de variabilidade nos preços dos ativos em LPS. O objetivo é a derivação de um framework conceitual extensível para as empresas. A abordagem torna possível criar variantes do sistema de software e servir a segmentos de mercado específicos. Müller [6] propõe um modelo matemático que visa determinar portfólio de produtos, que maximizem o lucro da empresa desenvolvedora da linha. Este modelo identifica os ativos que têm o maior impacto positivo no lucro. Ambos os problemas se preocupam particularmente com os preços dos ativos que compõem a LPS. Entretanto, restrições impostas pelos clientes, como orçamento disponível para aquisição do produto e importância dos ativos, não são considerados nestes trabalhos. Agradecimentos Este trabalho recebeu apoio financeiro da FAPEMIG, processos APQ-02376-11 e APQ02532-12, e do CNPq processo 485235/2011-0. Referências [1] Batory, D.; Sarvela, J. N.; Rauschmayer, A. Scaling Step-Wise Refinement. IEEE Transactions on Software Engineering, v.30, n.6, 355-371, 2004. [2] Cormen, T. et al. Introduction to algorithms. Cambridge, EUA: Massachusetts Institute of Tecnology. 2009. [3] Kiczales, G. et al. Aspect-Oriented Programming. In: European Conference on Object-Oriented Programming, pp. 220-242, 1997. [4] Loesch F. and Ploedereder E. Optimization of Variability in Software Product Lines. 11th International Software Product Line Conference, pp. 151-162, 2007. [5] Mendonça, M. et al. S.P.L.O.T. – Software Product Lines Online Tools. Int’l Conf. on OO Programing, Systems, Languages, and Applications (OOPSLA). 2009. [6] Müller J. Value-Based Portfolio Optimization for Software Product Lines. 15th International Software Product Line Conference, pp. 15-24, 2011. [7] Pohl, K.; Bockle, G.; Linden, F. J. v. d. Software Product Line Engineering: Foundations, Principles and Techniques. Springer-Verlag New York. 2005. [8] Product Line Hall of Fame. Disponível em: http://splc.net/fame.html [9] Sewerjuk D. Pricing of software product lines. In Bichler M. et al. editors, Multikonferenz Wirtschaftsinformatik, MKWI 2008, München, Berlin, 2008. [10] Simmonds J. et al. Analyzing Methodologies and Tools for Specifying Variability in Software Processes. Computer Science Department, Universidad de Chile, 2011. [11] Thum T. et al. FeatureIDE: An Extensible Framework for Feature-Oriented Software Development. Science of Computer Programming. 2012. 39 # !" $ ! # $ ! ! " % " # % " $ & ! " ( ) ! $ !$ $ & # ' $ & ! # # " $ " $ $ $ ' # # # % " !$ # * $ " +, ! & % ' . 0 '( () . ( & 1 " 2 #3 * + . 7 () ' 45 6 + , ' / ( () & ( 08 / - : ( - & #33945 18 5 : - ( 7 5 ' < 5> ( = , / ? 5 40 ( < 5 . + . . + . ( ( ( 0 & ( ( 6 ( 6 < . / ( + < 5 7 9934 . 6 : ; / - 6 ; ( / /( * + / , - 7 , + $ , -, * ( . ; + () 5 @ . , 1 0! 7 * ( 7 ( & * ; - * 7 & . . 9#A ( 1 - ' #33945 ? - * - ' & 5B 6 - ' () / 7 ) / / 0" - ( & %; $ #33C4 2 . ' & ( ( . 6 %; $ ( 56 / . ( / & - ' $ < ( - ' - ' #33945 ; @* ( , / . 0! ( ' + - . ' @ ' ( 5 '( ) * & #% ! #% % *+ () ? 5 ; . , 7 " 2 , ( #3 45 ; D / + - " ( / 5 %; $5 6 #%#% ' ( 6 & & 99E4 + - . / < 5 ( $ & %; $ 0" . () #33C4 + 2 ? ? / ( < ( ( . / 01 #%,% ( 5 %; $ . / / 0 + & : () 5B / 5 -, + %; $ ( , 1 01 # ( F D . 0 ' . ( & . / 0 F 5 & . () . 5 + / 1 *+ ( & / - . ? ( / '( + 6 0 . 0 / ( - 5 6 / . / 41 ( ( / 0 1" 2 . . ( ( ,% #3 45 6 , 5 0 1" 2 #3 45 '- ; - < - ' D , ' () / . = . - ! * - 1 @* 0 - #3 #41 %; $1 * > > - , & " % # # $ ' (# & : ' / JJ ( 56 ? / () > GH ( 5$ ( 1 " 2 / + KJ ( 7: #3 ( . I3 ( #I ( : L3 C5 B + ( 5 : + . / 0 5 ; & < - < 5 M ( * : . - ( . 7 5 B > > GH : / # . C ( + 56 / + # & @ O( O% & ( " ' / ( # # ( 25 ! * , . + > G5, G + N 5, G 56 ( + + ! + # $ : ( , #5 & ( 6 %; $5 + ! I 7 ( & : ( ( + , + * & & ) & -% 42 (+ 4 9 / / ' 0 ) .& ! (# - (# . ' 0 & . . (# . - 0 # ! ' . % ) 6 / / & - ' - + 0$ () 0* #3394 - 1 ( *5 - ' + - ' - . ( ( * - + / . + " ( 5 ) 6 & ? = . 1# / < & () % 0*M 1 >QN > #3 #4 * 08 #33J4 . *5 7 + ; - P 99K4 ? 2& I M ( M ( + & - * & 1L $ & 1 J ; + J () . %; $ > & D I5 ; & 7 / 1 1 C 1K $ ( + ( 1E & ( 5 1 2 3 4 5 6 7 8 ( ( & ! 5 K L( & + P#3 I ! C 7 P#3 I5 E P#3 I5 '( % ( * %; $5 ; 5 , , ( + / - & 2)& 0>'R / ( * ## + . ( & & 56 + LL & , & 43 7 #3 I4 ( & & ( & * 3 . + ( 3 & *5 , , & ( ( & -, ' . * . - < & 0 - #3 #45 " & 6 ( ;!M S 3#IEL 5 . & - @51 > 2! * () *51 " 2 M DM $5 ' 5 2 $51 * 51 (* F 8 5 851 $ > ' 8 ' @ 851 8 * @5 51 5 5 $ D - > 5 *5 G 6 M ; ' - S 2; ( ' G 6-, 5 C 9 CCI 99E5 >QN M ( ! 51 " ' 51 ! G F51 * G ) G ( 6 * () #3 I5 44 25 $ 5 M D M 5 9# 9E #33J5 %5 5 T51 H 5 !5 51 U 5 !5 51 * 5 5 '" 6 * () $ ! 5@ 5 L 5 KE E #3395 *M 5 M;;; *H 8 ) * () 6 25 5F ( ! J 99K5 5 * 2 ; 6 * () M *M P>QN > ; >'R >51 8V ;: ! * () 2* 5 * * H @ ( 5I3 5L IKK IE #33C5 *5 ' 5M D I'M ( 6-, @ " ;: 5 C# CI3 #3 5 51 % F5 51 B G H5 ;51 6$ - 2 * 25 * ( ) 5 ! P*;M 93 >@ # L 5 9935 5 ( 2 5 F5 * ( ) $ > ' 2 5I *51 - ' * () 9 33 #3395 ' ( ' %1 8 *51 ' D ;: ' * () ; ( D *5 2 ; ! 2& @ ) ( ;5 *2 25 M D L ' " & *2 *" @* 5 I3 I9 #3 #5 ) ( 6 5K 5 C9 JC #3395 F5 B51 @ * () ; > $ 6 2 5J - * () * () ; ( *51 8 ( 6-, > ' " 5 5 @51 %5 5 T51 ( * () ! ' @ 5 51 ! ' G - 2 51 $ 5 M D ; F? 2 M ( 5 7 5 51 ( > -% >QN > 5 C5# #3 #5 ' >5 M$;D 5 Extração de Conhecimento e Experiências em Equipes de Desenvolvimento Distribuído de Software Aluno: Rodrigo Gusmão de Carvalho Rocha Orientador: Silvio Romero de Lemos Meira Co-orientador: Ryan Ribeiro de Azevedo Nível: Doutorado Programa: Pós Graduação em Ciência da Computação do Centro de Informática da Universidade Federal de Pernambuco (CIn – UFPE) Email aluno: [email protected] Email orientador: [email protected] Email co-orientador: [email protected] Ano de Ingresso: 2010 Data da aprovação da proposta de tese/dissertação (qualificação): -Previsão de Conclusão: 2014 Resumo: A distribuição de equipes no desenvolvimento de software trouxe uma série de vantagens competitivas e também novos desafios, tais como, comunicação e compartilhamento de informação entre equipes distribuídas. Em outro contexto, o uso de Ontologias permite a formalização do conhecimento de um domínio. Em ambientes distribuídos a utilização de Ontologias traz alguns benefícios como compreensão uniforme das informações entre as equipes, facilidade de comunicação. O objetivo desta pesquisa é propor uma ferramenta e uma ontologia espefícica para ambientes distribuídos. A ferramenta auxilia os times distribuídos recomendando técnicas ou melhores práticas para evitar ou solucionar os desafios encontrados. Palavras-chave: Ontologias, Engenharia de software, Desenvolvimento distribuído de software, mapeamento sistemático. Sigla do evento do CBSoft Relacionado: SBES 45 1. Caracterização do Problema Há muitos anos, como reflexo da globalização, empresas de software começaram a distribuir seus processos de desenvolvimento em lugares diferentes, criando o desenvolvimento distribuído de software (DDS) (Herbsleb, 2007). Esta abordagem herdou os problemas existentes na forma tradicional e por diversas razões acrescentou outras dificuldades (Prikladnicki, 2004). Existem vários fatores técnicos e não técnicos que podem prejudicar o progresso dos projetos de software, um deles é o desenvolvimento de software com equipes geograficamente distribuídas, Projetos de software são formados por atividades temporárias, com objetivos, custos e responsabilidades definidas. Portanto, fica visível que é necessário desenvolver métodos que auxiliem na identificação das possíveis soluções para os fatores que podem levar ao fracasso projetos distribuídos. Dessa forma, inúmeras empresas tentam adotar técnicas, metodologias e ferramentas para que possam lidar da melhor forma com as variáveis do contexto distribuído. Contudo, é necessário que existam mais estudos para que sejam concebidas novas técnicas, metodologias e ferramentas para ambientes distribuídos (Lopes et al, 2003)(Rocha et al, 2008). Em diversos momentos, as empresas que utilizam esse modelo de desenvolvimento necessitam definir recursos e estratégias que irão adotar para um determinado projeto e suas respectivas práticas, para tanto, estas não provêem de informações que sejam capazes de determinar quais melhores estratégias e os melhores recursos são mais adequados para determinado tipo de projeto ou quais as práticas mais indicadas para o mesmo. Nesse contexto, este trabalho tem como objetivo explorar experiências passadas de DDS, usando uma base de conhecimento para facilitar a alocação de novos projetos e definição de boas práticas para os mesmos. O que seria uma alternativa para solucionar e/ou mitigar problemas no decorrer de um projeto. Para tanto, é necessário, definir uma ontologia para o contexto distribuído e desenvolver uma aplicação que faça inferências através da ontologia criada. O principal objetivo deste trabalho é conceber uma base de conhecimento para o Desenvolvimento Distribuído de Software que pode ser usada através de uma ferramenta para ajudar a resolver problemas nesse contexto, mitigando riscos, minimizando custos inerentes aos projetos, melhorando a comunicação, disponibilizando informações sobre times de desenvolvimento, pessoas, recursos, técnicas e metodologias, entre outros conhecimentos. Então, os objetivos específicos são: − Formalizar e desenvolver estruturas padronizadas para representação de informações (Ontologias) sobre DDS para especificar, tratar e mitigar riscos em projetos distribuídos − Preencher base de conhecimento das ontologias com base na metodologia proposta pela própria ontologia 46 − Identificar fatores que afetam negativamente e positivamente o Desenvolvimento Distribuído de Software e através do conhecimento de especialistas na área propor as possíveis soluções − Desenvolver a arquitetura do sistema que vai ter acesso a essa base de conhecimento − Desenvolver a ferramenta para criação, manipulação, extração de informações, avaliação e validação das ontologias desenvolvidas provendo suporte à metodologia e integrado a arquitetura para criar e armazenar protótipos de problemas e suas soluções − Aplicar a Ferramenta e a base de conhecimento em equipes distribuídas a fim de validar a proposta 2. Fundamentação Teórica Nesta seção estão descritas os três principais conceitos envolvidos nessa pesquisa, o desenvolvimento Distribuído de Software, Mapeamento Sistemático e Ontologias. 2.1. Desenvolvimento Distribuído de Software O desenvolvimento de software de forma co-localizada tem se tornado cada vez mais custoso e menos competitivos para as organizações. Visando a redução de custos, a disponibilidade de profissionais mais especializados, o aumento da produtividade e a competitividade global, várias empresas adotam o DDS (Audy e Prikladnicki 2008). O DDS é um modelo de desenvolvimento de software onde os envolvidos em um determinado projeto estão dispersos. As características fundamentais deste modelo de desenvolvimento são: a distância física, a diferença de fuso horário e as diferenças culturais entre os envolvidos no processo. Entretanto, existe uma serie de desafios inerentes a este ambiente. Os principais desafios são: dispersão geográfica, coordenação, comunicação reduzida e espírito de equipe (Carmel 1999). 2.2. Mapeamento Sistemático Revisões sistemáticas e mapeamentos sistemáticos provêem meios para executar revisões na literatura mais abrangentes e não tendenciosas, produzindo resultados com maior valor científico, conforme mencionado por Travassos e Biolchini (2007). Essas revisões de literatura têm por objetivo apresentar uma justa avaliação de um tópico de investigação, usando uma confiável, rigorosa e auditável metodologia (Kitchenham 2007). Uma revisão ou mapeamento sistemático começa com a definição do protocolo de pesquisa, que especifica as questões de investigação e os métodos que serão usados para conduzi-la. Depois são realizadas as buscas e avaliações dos estudos primários, de acordo com os critérios definidos no protocolo. Posteriormente é feita a extração e síntese dos dados relevantes para a questão de pesquisa, além da publicação dos resultados. No final, é elaborado um relatório, onde são mapeadas as informações levantadas durante a revisão. 47 2.3. Ontologias O conceito de ontologia surgiu na área da Filosofia, como uma forma de descrever os objetos do mundo real. Nas últimas décadas, as ontologias também vêm sendo estudadas na área de Ciências da Computação, onde é utilizada como uma forma de representar e compartilhar conhecimento. Gruber (1993) define ontologia como “uma especificação explícita de uma conceituação”. De acordo com Tercio (2003), a utilização de ontologias permite estruturar de forma mais clara o conhecimento de um contexto. Além disso, a utilização de um domínio pré-definido, através de ontologias, permite uma definição mais precisa e provê consistência semântica à informação. Assim, ontologias representam um excelente mecanismo para formalizar um padrão de compartilhamento de conhecimento entre pessoas ou agentes de software. 3. Contribuições Esta pesquisa tem o objetivo de trazer contribuições para a Engenharia de Software, especificamente para projetos distribuídos. Dessa forma, é se destacam as três principais contribuições: • Realização de um mapeamento sistemático para identificar evidências para o estado da arte do desenvolvimento de software com equipes distribuídas. Com esse mapeamento, foi possível identificar trabalhos que utilizam recursos de ontologia, sejam esses recursos, ferramentas baseadas em ontologias, ontologias específicas de alguma fase do desenvolvimento de software, ontologias formalizadas para o DDS e ontologias de ES que podem ser utilizadas dentro de um projeto nesse contexto. • A segunda contribuição é a modelagem formal de um domínio, que será através da ontologia. O que permitirá conceber uma base de conhecimento para Desenvolvimento Distribuído de Software que poderá ser utilizada para ajudar a resolver problemas nesse contexto, mitigando riscos, minimizando custos inerentes aos projetos, melhorando a comunicação, disponibilizando informações sobre recursos, técnicas e metodologias, entre outros conhecimentos. • A terceira contribuição importante é uma ferramenta desenvolvida que tem acesso a essa base de conhecimento para obter informações a respeito de evitar desafios ou obter possíveis soluções adodatas em projetos semelhantes. 4. Estado Atual do Trabalho Nesta seção é apresentado o estado das atividades realizadas no decorrer deste trabalho, bem como seus resultados. 4.1 Mapeamento Sistemático Nessa seção é apresentado o processo de busca pelos estudos primários. As buscas dos artigos foram realizados de acordo com os plano de pesquisa definido no protocolo. O resultado da pesquisa retornou 1389 estudo a partir das bases cientificas escolhidas. 48 Após o procedimento de seleção descrito no protocolo 37 artigos relevantes foram selecionados. Na Tabela 1 é apresentado a distribuição desses trabalhos para cada base e tipos de estudos retornados. Tabela 1. Resultado do Processo de Seleção de Estudos Primários Pesquisa Resultados da Pesquisa Estudos Relevantes Não Relevantes Repetidos Incompletos Estudos Primários ACM 228 37 26 7 2 2 IEEE 531 119 85 9 6 19 EI Compendex 53 21 5 16 0 0 Science Direct 218 38 27 7 1 3 Scopus 357 66 23 30 2 11 Manual 2 2 0 0 0 2 Total 1389 283 166 69 11 37 O mapeamento não foi restrito a período de publicações, embora todos os estudos selecionados tenham sido publicados entre 2001 e 2011. É importante destacar também que a maior parte dos estudos foram publicados entre 2006 e 2011, o que demonstra que a relevância desse tema vem aumentando nos últimos anos. Baseado nos estudos primários que são referentes a ontologias para o DDS, onde eles foram automaticamente considerados como trabalhos relacionados pelo fato de abordam ontologias específicas para DDS, é possível afirmar que trabalhos que propõe ontologias para Engenharia de Software são poucos e para o cenário de desenvolvimento distribuído o número de ontologias é bem inferior. A diferença essencial desse trabalho é a proposta da Ontologia específica dessa ontologia é a utilização das classes BestPractices e Challenges. Onde o objetivo é o uso de boas práticas para os problemas encontrados pelos membros. Essa Ontologia permite que outros sistemas possam acessá-la para extração de importantes informações, como por exemplo, na fase inicial do projeto ser gerada uma lista com as melhores práticas a serem adotadas para o projeto, essa lista é gerada baseada no conhecimento armazenado de outros projetos com configuração semelhante. Para atualizar o mapeamento sistemático, novas buscas serão realizadas até o final do trabalho, acrescentando o último ano para busca, no caso, 2013. Essas novas pesquisas serão manuais em períodicos e conferências internacionais que não são indexados pelas bibliotecas digitais. Outras buscas serão realizadas nos mesmos engenhos utilizados, acrescentado apenas os anos de 2012 e 2013. Para maiores informações e maiores detalhes sobre todo o procedimento adotado no mapeamento sistemático e os resultados encontrados, bem como a análise desses resultados, é possível acessar o endereço: http://rgcrocha.com/ms/ . 49 4.2 DKDOnto - Ontologia Proposta Este trabalho propõe uma Ontologia chamada de DKDOnto, desenvolvida para utilização de projetos e empresas que trabalham com o conceito de desenvolvimento global de software. Embora existam diversas metodologias que podem ser utilizadas como guia ou para suporte na construção de uma ontologia, não há uma que seja padrão. O primeiro passo foi definir as questões de competência, o segundo foi identificar os termos do domínio de conhecimento e em seguida, fazer a identificação das classes da ontologia. O passo seguinte para melhor foi a construção da Ontologia em si. Dessa forma, a ferramenta de modelagem utilizada foi o Protégé 4.0 (Protégé, 2013) e a linguagem de modelagem foi a OWL-DL (OWL-DL, 2013). O passo seguinte, será a aquisição do conhecimento, para preenchimento da ontologia. A técnica utilizada para adquirir esse conhecimento será um survey com empresas e equipes que já vivenciaram projetos, através de entrevistas ou questionários. Por fim, o último passo será a validação da DKDOnto, essa validação se dará por meio de acompanhamento da ontologia em empresas. 4.3 Proposta da Ferramenta Ferramenta de apoio à tomada de decisões em projetos no DDS, com base nos recursos e informações do contexto do projeto, o sistema sugere aos usuários as possíveis soluções para os problemas encontrados. Dessa forma, o sistema acessa uma base de dados com as de experiências de projetos distribuídos, com as configurações dos projetos e com desafios encontrados e as soluções utilizadas para as fases do desenvolvimento. Essa ferramenta tem como objetivo principal apoiar a gerência de projetos na resolução de problemas em ambientes distribuídos, oferecendo recomendações com base em atributos do projeto (configuração) e experiências técnicas, não técnicas e organizacionais. As principais funcionalidades da ferramenta são: • Inserir configurações do projeto • Inserção de problemas para um determinado contexto • Inserção de soluções adotadas para desafios encontrados num determinado contexto • Solicitar uma lista (como um guideline) com sugestão de boas práticas para contextos semelhantes (início de projeto) • Buscar possíveis soluções para problemas encontrados • Avaliar as soluções proposta pela ferramenta • Sugerir adaptações para as soluções propostas Por fim, a validação da ferramenta será dentro de empresas de software, buscando identificar as lacunas e as melhorias que a ferramenta pode necessitar, para correção ou implementação de complemento. 50 5. Trabalhos Relacionados Wongthongtham et al. [PS02] apresenta um sistema baseado em ontologias para o suporte ao DDS. Esse sistema é formado por agentes de software que utilizam um repositório de conhecimento que envolve 4 ontologias: de domínio, de dados do projeto, de engenharia de software e de gerenciamento de projetos. Com base nesse repositório, os agentes são capazes de classificar problemas inseridos por usuários e retornar possíveis soluções, além de gerenciar o acesso e alteração de dados do projeto. Ajmeri et al. [PS16] apresenta um sistema de recomendações utilizado no processo de especificação de requisitos de software em ambientes ágeis e distribuídos, onde a equipe de analistas de requisitos tem uma base de conhecimentos associados ao domínio do projeto e pode utilizá-la para tomar decisões durante a elicitação dos requisitos. A base de conhecimento do sistema integra quatro ontologias: domínio do negócio, requisitos ágeis, requisitos genéricos e estrutura do ambiente. O sistema ainda fornece recomendações em tempo real baseadas em inferências realizadas nas ontologias e permite que a base de conhecimento seja realimentada pelos analistas de requisitos. 6. Resultados Esperados O que se espera deste trabalho ao final, é que exista uma base de conhecimento que possa ser utilizada como fonte de pesquisa e utilização por parte de empresas nacionais e internacionais que utilizam o Desenvolvimento Distribuído de Software. A ontologia proposta contém informações sobre os projetos no contexto distribuído incluindo desafios encontrados e soluções utilizadas, dessa forma, através da ferramenta que está sendo desenvolvida durante este trabalho -e utilizará técnicas e métodos para inferência e dedução- qualquer membro da equipe ou preferencialmente a gerência pode consultar a ferramenta e a base, para tentar evitar ou remediar problemas durante a execução do seu projeto. Esta proposta apresenta uma possível solução para a diminuição ou prevenção de alguns problemas que são enfrentados no contexto distribuído, já que esse problemas existem e não são iguais aos problemas do desenvolvimento tradicional de software (colocalizado), são os mesmos somados a outros fatores. Dessa forma é necessário que existam formas de prevenir ou remediar riscos e problemas em ambientes distribuídos. Esse trabalho é validado basicamente de duas formas, a primeira validação é com a ontolodia e a segunda forma, que é a validação da ferramenta. A ontologia desenvolvida e preenchida pelo conhecimento de profissionais de Engenharia de Software(ES), nas mais diversas sub áreas de ES através de entrevistas, revisão literaria ou utilização direta dos usuários. A ferramenta em si, será testada e validada em projetos reais, projetos que envolverão pequenas e grandes equipes, distâncias geograficas e temporais pequenas e grandes . Dessa forma, será possível visualizar como a ferramenta vai se portar para levar o melhor resultado de informação requisitada pelo usuário. 51 Referências Ajmeri, N., Sejpal, R., Ghaisas, S. 2010 “A Semantic and Collaborative Platform for Agile Requirements Evolution”. Audy, J. L. N., Prikladnicki, R., Desenvolvimento Distribuído de Software, Editora Elsevier, 2008. Gruber, T., A Translaction Approach to Portable Ontology Specifications. Relatório Técnico, Knowledge Systems Laboratory, Computer Science Department. Stanford University, 1993. Herblesb. J. D. (2007). “Global Software Engineering: The Future of Socio-technical Coordination”. IEEE Computer Science. P188-198. Kitchenham, B., “Guidelines for performing Systematic Literature Reviews in Software Engineering”, EBSE Technical Report (EBSE’2007), Department of Computer Science, University of Durham, UK, 2007. Lopes, Leandro; Prikladnicki, Rafael; Majdenbaum, Azriel; Audy, Jorge. ( 2003). “Uma proposta para processo de requisitos em ambientes de desenvolvimento distribuído de software”. In: 6th WER, Piracicaba. Brasil. Proceedings... p. 329-342. OWL-DL, 2013. OWL Web Ontology Language. [Online]. http://www.w3.org/TR/owlfeatures Prikladnicki, R.; Lopes, L.; Audy, J.; Evaristo, R. (2004). Desenvolvimento Distribuído de Software: um Modelo de Classificação dos Níveis de Dispersão dos Stakeholders, I Simpósio Brasileiro de Sistemas de Informação, Porto Alegre. Protègè, 2013. The Protégé Ontology Editor. [Online]. http://protege.stanford.edu Rocha, R. Arcoverde D. Brito, R. Aroxa, B. Costa, C. Silva, F. Q. B. Albuquerque, J. Meira, S. R. L. (2008). “Uma Experiência na Adaptação do RUP em Pequenas Equipes de Desenvolvimento Distribuído”. II Workshop de Desenvolvimento Distribuído de Software (SBES-SBBD). pp. 87-96. Tercio, M. S., “Extração de Informações para Busca Semântica na Web Baseada em Ontologias”, Dissertação de Pós-graduação em Engenharia Elétrica, Universidade Federal de Santa Catarina, Florianópolis, 2003. Travassos, G. and Biolchini, J., “Revisões Sistemáticas Aplicadas à Engenharia de Software”, XXI Brazilian Symposium on Software Engineering (SBES), Brasil, 2007. Wongthongtham, P., Chang, E., Dillon, T., “Ontology-Based Multi-Agent System to Multi-Site Software Development”, Proceedings of the 2004 Workshop on Quantitative Techniques for Software Agile Process, 2004. 52 Identificação de Bad Smells em Softwares a partir de Modelos UML Henrique G. Nunes1, Mariza A. S. Bigonha1, Kecia Aline Marques Ferreira2 1 2 Departamento de Ciência da Computação – Universidade Federal de Minas Gerais (UFMG) - Belo Horizonte – MG – Brasil Departamento de Computação – Centro Federal de Educação Tecnológica de Minas Gerais (CEFET-MG) - Belo Horizonte – MG – Brasil. [email protected], [email protected], [email protected] Resumo. Métricas de software podem auxiliar na identificação de desvios de projeto, conhecidos na literatura como bad smells. Alguns trabalhos têm utilizado essa abordagem para a avaliação de código-fonte. Todavia, é importante a existência de métodos que permitam a identificação de problemas estruturais nas fases iniciais do ciclo de vida do software. A dissertação apresentada neste artigo visa contribuir nesse aspecto, propondo um método e uma ferramenta para a identificação de bad smells, via métricas de software, em sistemas orientados por objetos a partir de modelos UML. 1. Caracterização do Problema Assim como nos códigos-fonte, as métricas obtidas a partir de modelos UML podem permitir analisar confiabilidade, manutenibilidade e complexidade de um sistema. Dentre os diagramas da UML, destaca-se o diagrama de classes que representa classes de objetos e suas relações (Yi et al., 2004). A análise desse diagrama pode fornecer métricas relacionadas à manutenibilidade e complexidade do software no início do projeto, como o número total de classes, métodos e relacionamentos, por exemplo. Porém, em um projeto real é inviável calcular tais métricas manualmente (Girgis et al., 2009). O objetivo desta dissertação é definir um método de identificação de bad smells em softwares a partir de modelos UML. Para a definição desse método, inicialmente serão identificados os principais bad smells relacionados à manutenibilidade de software. A partir daí, serão identificadas as métricas de software que podem auxiliar a detectá-los em modelos UML, bem como os valores referência propostos na literatura para tais métricas. Uma ferramenta para aplicação do método proposto está em fase de desenvolvimento. 2. Fundamentação Teórica Fowler (1999) define bad smell como um indicador de possível problema estrutural em código-fonte, que pode ser melhorado via refatoração. Dentre os bad smells descritos na literatura, foram selecionados inicialmente para a realização deste trabalho: • God Class: classes que tendem a centralizar a inteligência do sistema (Marinescu, 2002). 53 • Shotgun Surgery: a mudança em uma classe que gera pequenas mudanças em muitas outras classes (Marinescu, 2002). • Indecent Exposure: quando uma classe revela dados internos (Hamza, 2008). Métrica de software é um valor numérico relacionado a algum atributo de software, permitindo, dentre outros aspectos, a comparação entre atributos da mesma natureza (Sommerville, 2011) e a identificação de componentes com bad smells. Marinescu (2004) define estratégia de detecção como “uma expressão quantificável de uma regra, que permite avaliar se fragmentos de código estão de acordo com essa regra”. Para definir formalmente alguns bad smells, Marinescu (2004) e Lanza & Marinescu (2006) usam técnicas das estratégias de detecção como mecanismos de filtragem e composição, que aplicam métricas e valores referência. Bertrán (2009) afirma que por meio da adaptação de estratégias de detecção definidas por Marinescu (2004), projetistas podem localizar diretamente classes e métodos em modelos UML afetados por um bad smell particular, em vez de deduzir o problema a partir de um extenso conjunto de valores anormais de métricas. 3. Trabalhos Relacionados Há na literatura algumas ferramentas que têm como objetivo fornecer dados sobre um projeto de software por meio do uso de métricas de modelos UML. Dentre elas destacam-se as propostas por Girgis et al. (2009), Soliman et al. (2010) e Nuthakki et al. (2011), que realizam coleta de métricas em diagramas de classes. Porém, essas ferramentas limitam-se à coleta de métricas, sem reportarem recomendações de melhorias nos projetos. Marinescu (2002) realizou um dos principais trabalhos sobre estratégias de detecção de bad smells em software orientado por objetos a partir de métricas de software. As estratégias definidas por ele se baseiam em definir valores limites para as métricas utilizadas na detecção de bad smells. Porém, ele não define precisamente os valores limites a serem considerados. Bertrán (2009) utiliza métricas de software para definir regras que identifiquem bad smells em diagramas de classes. Todavia, da mesma forma que Marinescu (2002), não são definidos, de forma sistemática, valores referência das métricas para a identificação dos bad smells. O trabalho de Bertrán (2009) explora a identificação de problemas estruturais em software a partir de modelos UML, todavia é restrito na quantidade de métricas em que se baseia. O trabalho proposto nessa dissertação visa propor melhorias nos métodos de identificação de problemas arquiteturais em software orientado por objetos a partir de modelos UML. Para isso, será definido um método baseado em métricas e seus valores referência. A principal diferença entre a abordagem adotada no presente trabalho e a de trabalhos anteriores é que serão avaliadas novas possíveis métricas para representar os bad smells definidos por Fowler (1999), não se limitando ao que é definido em Marinescu (2002) e Bertrán (2009). Outra diferença será a escolha de métricas com valores referência definidos na literatura, em vez de utilizar valores arbitrários. 54 4. Estado Atual do Trabalho Para a definição do modelo, foi realizada uma revisão da literatura para a identificação de bad smells a serem considerados, bem como as métricas a serem utilizadas. Os valores referência utilizados são aqueles definidos por Ferreira et al. (2012). A ferramenta para aplicação do modelo está em desenvolvimento e já permite a realização de análise dos bad smells que foram identificados na Seção 2. As métricas utilizadas e os bad smells que elas identificam estão na Tabela 1. Tabela 1. Bad Smells e métricas utilizados nos experimentos preliminares Bad Smell Referências Métricas Nº de métodos públicos (NMP) God Class (Large Class) Marinescu (2002) e Fowler(1999) Nº de conexões aferentes (NCA) Shotgun Surgery Marinescu (2002) Nº de conexões aferentes (NCA) Indecent Exposure Hamza (2008) Nº de atributos públicos (NAP) Valores Referência médio: 11 a 40 ruim: > 40 médio: 2 a 20 ruim: >20 médio: 2 a 20 ruim: >20 médio: 1 a 10 ruim: >10 As questões de pesquisa avaliadas no experimento preliminar foram: RQ1 : Os resultados obtidos automaticamente pela ferramenta estão de acordo com o que foi identificado pelos especialistas? RQ2 : A utilização dessas métricas e seus valores referência foram úteis para identificação de bad smells? A ferramenta desenvolvida tem como objetivo identificar bad smells em modelos UML a partir de diagramas de classes. Como não havia um repositório de diagramas de classes a disposição, utilizou-se a engenharia reversa do software Enterprise Architecture para que fosse possível a realização do experimento e para verificar se a metodologia adotada identifica bad smells nos diagramas. Exportou-se o diagrama de classes para o formato de arquivo XMI, por ser o modelo mais utilizado nos estudos avaliados do referencial teórico. Os estudos preliminares foram realizados no diagrama de classes obtido a partir da engenharia reversa do software Mobile Media (2013), Versão 9. O software foi desenvolvido em Java, possui 56 classes e 4 interfaces, e trata-se de um aplicativo móvel para gerenciar imagens, músicas e vídeos. Dois especialistas avaliaram o diagrama de classes para apontar classes com os bad smells avaliados. O primeiro especialista é um aluno de graduação que já cursou disciplinas relacionadas a programação modular e trabalha em projetos de iniciação científica na área de linguagens de programação. O segundo especialista é um Analista de Sistemas, que possui experiência de 8 anos em diagramas UML e programação Orientada por Objetos. Ambos apontaram as classes problemáticas em seu ponto de vista. Em seguida, o diagrama de classes foi submetido à análise da ferramenta. Os resultados reportados pela ferramenta foram comparados com as conclusões obtidas pela análise dos especialistas. 55 5. Avaliação dos Resultados Para avaliação do Indecent Exposure, utilizou-se a métrica NAP como regra. Sete classes atingiram valores regulares para a métrica, variando entre 2 a 8. Embora elas não apresentem valores ruins para a métrica, elas não foram implementadas dentro dos valores ideias para a métrica. Uma classe atingiu um valor acima do valor referência considerado crítico, pois declara 17 atributos como públicos. As classes identificadas pelos especialistas estavam todas dentro dos valores ruins ou regulares identificados pela ferramenta. Para calcular o Shotgun Surgery, utilizou-se a métrica de cálculos de conexões aferentes. De acordo com a ferramenta proposta, duas classes estão com valores ruins para a métrica NCA, se comparadas com os valores referência definidos por Ferreira et al. (2012), sendo 24 e 25 os valores encontrado para as duas. Pela ferramenta, ainda foram identificadas outras classes com valores entre 16 a 9 como valores regulares. Todas essas classes foram citadas na avaliação dos especialistas. Porém, outras classes com valores de 2 a 6 foram apontadas como regulares pela ferramenta, mas não foram citadas pelos especialistas. A métrica NMP associada à NCA possibilita a identificação da ocorrência do bad smell God Class. Nos experimentos, uma classe apresentou valores razoáveis em ambas as métricas. Duas outras classes possuem um nível regular na métrica NMP e atingiram valores ruins na métrica NCA. O resultado é confirmado pela análise dos especialistas, que concluíram que a estrutura de ambas pode ser dividida em outras classes. A resposta para a primeira questão de pesquisa é positiva, pois a maioria das classes avaliadas como problemáticas pelos especialistas atingiram níveis médio e ruim pela avaliação da ferramenta. A resposta da segunda questão de pesquisa também é positiva, pois foi possível identificar classes problemáticas utilizando os valores referência definidos na literatura. Esse estudo preliminar indica que o método proposto permite identificar bad smells a partir de modelos UML satisfatoriamente. Todavia, outros experimentos necessitam ser realizados. Além disso, outros bad smells deverão ser analisados no estudo. 6. Contribuições O trabalho realizado nessa dissertação visa contribuir com a definição de um método para identificação de problemas estruturais em software nas fases iniciais do seu ciclo de vida. Os resultados desse trabalho gerarão as seguintes contribuições principais: 1. Definição um método de identificação de bad smell a partir de diagramas de classe da UML, utilizando métricas de software e seus valores referência. 2. Disponibilização de uma ferramenta que dê suporte para engenheiros de software na identificação de bad smells no início do projeto. 7. Conclusões Essa dissertação de mestrado tem por objetivo a definição de um método para identificação de problemas estruturais em software nas fases iniciais do projeto. O método proposto consiste na identificação de bad smells em modelos UML, aplicando-se métricas de software e seus respectivos valores referência. 56 Este artigo relata os resultados preliminares do trabalho. Os resultados da análise dos especialistas e da ferramenta foram parecidos. Na continuidade do trabalho, será implementada a coleta de outras métricas e serão estudados outros bad smells que possam ser identificados com auxílio delas e de seus valores referência. Serão realizados experimentos com outros softwares abertos a fim de se avaliar o método proposto. Referências Bertrán, I. M. Avaliação da qualidade de software com base em modelos uml. Dissertação de Metrado da Puc Rio, Rio de Janeiro, 2009. Ferreira, K. A. M. ; Bigonha, M. A. S. ; Bigonha, R. S. ; Mendes, L. F. O. ; Almeida, H. C. . Identifying thresholds for object-oriented software metrics. The Journal of Systems and Software, v. 85, p. 244-257, 2012. Fowler, Martin. Refactoring: improving the design of existing code. Addison-Wesley Professional, 1999. Girgis, Moheb R., Tarek M. Mahmoud, and Rehab R. Nour. "UML class diagram metrics tool." Computer Engineering & Systems, 2009. ICCES 2009. International Conference on. IEEE, 2009. Hamza, H., et al. "Code smell eradication and associated refactoring." Proceedings of the European Computing Conference (ECC). 2008. Lanza, M.; Marinescu, R. & Ducasse, S. Object-Oriented Metrics in Practice. SpringerVerlag New York, Inc., Secaucus, NJ, USA, 2005. Marinescu, Radu. "Measurement and quality in object-oriented design." Software Maintenance, 2005. ICSM'05. Proceedings of the 21st IEEE International Conference on. IEEE, 2005. Marinescu, R. Detection strategies: metrics-based rules for detecting design flaws. In Software Maintenance, 2004. Proceedings. 20th IEEE International Conference on, pp. 350 – 359, 2004. Mobile Media (2013). http://sourceforge.net/projects/mobilemedia/. Acessado em 31/07/2013. Nuthakki, M. K.; Mete, M.; Varol, C. & Suh, S. C. Uxsom: Uml generated xml to software metrics. SIGSOFT Softw. Eng. Notes, 36(3):1—6, 2011. Soliman, T.; El-Swesy, A. & Ahmed, S. Utilizing ck metrics suite to uml models: A case study of microarray midas software. In Informatics and Systems (INFOS), 2010 The 7th International Conference on, pp. 1 –6, 2010. Sommerville, Ian. Engenharia de software. Vol. 8. São Paulo: Addison Wesley, 2007. Yi, T.; Wu, F. & Gan, C. A comparison of metrics for uml class diagrams. SIGSOFT Softw. Eng. Notes, 29(5):1—6, 2004. 57 Infraestrutura Para Criação de Jogos Voltados para o Ensino de Programação no Ensino Médio Tainá Medeiros1, Eduardo Aranha1 1 Programa de Pós-Graduação em Sistemas Computacionais – PPgSC Universidade Federal do Rio Grande do Norte – UFRN Caixa Postal 1524 – Campus Universitário Lagoa Nova – CEP 59072-970 – Natal/RN – Brasil {tainajmedeiros, eduardohsaranha}@gmail.com Abstract. The use of information and communication technologies offer students interactive media can enrich lessons and help in the learning process. Digital games offer a potential that can be used to help and motivate students in their learning. In the teaching of programming, this technology can be a very useful tool. Therefore, this paper aims to present a proposal for teaching programming via digital games, using as a basis the development tool Construct 2 games, and Blockly, visual programming environment based on the web. Resumo. O uso das tecnologias de informação e comunicação oferecerem aos alunos mídias interativas que podem enriquecer as aulas e ajudar no processo de aprendizagem. Os jogos digitais oferece um potencial que pode ser utilizado para ajudar e motivar estudantes na sua aprendizagem. No ensino de programação, esta tecnologia pode ser uma ferramenta de grande utilidade. Portanto, o presente artigo tem como objetivo apresentar uma proposta de ensino de programação através jogos digitais, utilizando como base a ferramenta de desenvolvimento de jogos Construct 2, e o Blockly, ambiente de programação visual baseado na web. 1. Introdução e caracterização do problema Os jogos digitais vêm sendo considerados como um instrumento educativo capaz de contribuir tanto para o desenvolvimento da educação, como para a construção do conhecimento. A atividade de jogar precisa ser considerada em seu todo como uma forma de apoio dentro da educação para o desenvolvimento de muitas competências e habilidades do aluno, lhe servindo como estímulo enquanto este se encontra em fase de aprendizagem [Grado e Tarouco 2008]. Este ano a Folha de São Paulo apresentou uma reportagem apontando que embora existam muitos jogos educativos disponíveis na Internet, a oferta de boas ferramentas não é grande [Rewald 2010]. A reportagem mostrava uma experiência em que alunos de um colégio brasileiro desenvolveram jogos e relatava que o interesse era tão grande por parte dos alunos que vários passavam o intervalo desenvolvendo os jogos. Nesta perspectiva de que existe a necessidade da sociedade de jogos educativos com alguns indicadores de que ensinar jovens a desenvolver jogos pode aumentar o seu interesse por computação [Ceder e Yergler 2003], este trabalho propõe o ensino de 58 programação através em jogos digitais, ou seja, um ensino contextualizado, lúdico e bastante atrativo. Será proposta uma abordagem de ensino de lógica de programação. Para isto, está sendo desenvolvido uma infraestrutura para criação de jogos com essas características fazendo uso de dois ambientes, o Construct 2 e o Blockly. 2. Fundamentação Teórica Essa Seção irá apresentar uma breve fundamentação sobre jogos digitais para ensino, como também as ferramentas construct 2 e blockly. De forma a elaborar a proposta deste trabalho. 2.1. Jogos Digitais voltados ao Ensino Os jogos digitais para ensino são atividades inovadoras onde as características do processo de ensino-aprendizagem apoiado no computador e as estratégias de jogo são integradas a fim de alcançar um objetivo educacional determinado. Esta estratégia, num jogo planejado adequadamente, promove o interesse e a motivação que por sua vez, aumentam a atenção do aluno e criam a sensação de que aprender é divertido, proporcionando ao jogador desenvolver a capacidade de processar fatos e fazer inferências lógicas durante a resolução de um problema [Morati, 2003]. 2.2. Ferramentas de auxilio a criação de jogos e ensino de programação Nossa proposta tem o auxilio de duas ferramentas, são elas: o Construct 21, um ambiente criado pela Sicrra que ajuda na criação de jogos digitais 2D em HTML5 com grande apelo visual e facilidade de programação, onde a codificação é feita de forma visual;; e o Blockly2, um ambiente baseado na web para edição de programação de uma forma gráfica, é executado em um web-browser, ou seja, não há necessidade de fazer downloads ou instalar plugins. O trabalho faz uma ligação entre essas duas ferramentas para obter uma estrutura de ensino de programação através de jogos digitais, que é o objetivo proposto pelo trabalho. 3. Proposta de jogos voltados para o ensino de programação Os estudantes são apresentados a um cenário e convidados a explora-lo, inicialmente, jogando através de movimentos pré-definidos pelo teclado para conhecer todo o cenário e objetos presentes no jogo. Após ter o domínio de todos os comportamentos possíveis dos objetos contidos no cenário do jogo, o jogador terá como missão jogar novamente utilizando o auxilio de blocos de programação, construindo de maneira lógica o passo a passo dos comportamentos dos objetos, até a conclusão do jogo. 3.1. Arquitetura dos jogos A arquitetura dos jogos a serem desenvolvidos com a infraestrutura proposta está organizada em camadas que podem ser visualizadas na Figura 01. O jogo é executado 1 Possui licença gratuita (limitada) e licenças pagas, com preço bastante acessível para escolas. https://www.scirra.com/construct2. 2 Editor de programação visual open-souce. https://code.google.com/p/blockly/ 59 via web e sua arquitetura está organizada em camadas de componentes, cenários- desafios, editor de programação e a API de integração. Figura 01- Arquitetura do Protótipo Na camada de componentes encontram-se os objetos desenvolvidos através do Construct 2, que serão utilizados nos cenários-desafios dos jogos. O editor de programação que está sendo utilizado, o Blockly, irá ditar os comportamentos de cada componente utilizado no jogo. Para integrar o cenário com o editor de programação, foi criada uma API com conjunto de rotinas e padrões estabelecidos, ou seja, integrar os ambientes Construct 2 e Blockly para que sejam utilizados pelo aluno. 4.2. Mecânica do jogo O protótipo do jogo contêm um cenário, os objetos e um ambiente de programação. No cenário podem ser vistos os objetos: guindaste e caminhão. A visão geral do protótipo pode ser vista na Figura 02. Figura 02- Visão Geral do Protótipo 60 O desafio para o jogador, neste exemplo, será o de programar o comportamento desses objetos de modo que siga os seguintes passos: O guindaste 1 irá pegar o contêiner e coloca-lo no caminhão de carga, o caminhão andará até o guindaste 2, para que então, esse guindaste pegue o contêiner do caminhão e coloque em cima do navio. O ambiente de programação contém as instruções dos possíveis comportamentos de cada objeto, onde o jogador poderá montar seu bloco de comandos e mover adequadamente os objetos para que seja finalizado o jogo. 4.3. Resultados iniciais O protótipo do jogo apresentado na Figura 2 encontra-se em fase de conclusão e será utilizado posteriormente, juntamente com outros cenários, para realizar um estudo de caso com alunos do ensino médio. Será utilizado em oficinas nas escolas com o objetivo de fazer uma analise da desenvoltura da criança em relação ao ensino de programação, obtendo como resultados relatórios sobre o desenvolvimento do jogo, criado por cada criança. Através destes resultados poderemos avaliar esta proposta de utilizar jogos para o ensino de programação. 5. Trabalhos relacionados Há alguns projetos de jogos digitas no ensino que se sobressai devido a sua natureza multidisciplinar. O Robocode é um jogo de programação, cujo objetivo lúdico é programar um tanque de guerra para enfrentar outros tanques desenvolvidos da mesma forma. O objetivo sério deste jogo é facilitar a aprendizagem das linguagens Java e C#, bem como a aprendizagem de inteligência artificial [Larsen, 2013]. O M.U.P.P.E.T.S. é um sistema multi-utilizador desenhado para permitir aos alunos desenvolver objetos em Java, bem como criar robôs da mesma forma que o Robocode permite, no entanto com um grau de customização superior. A representação visual do mundo virtual e dos objetos criados é feita em 3D e contem ferramentas para importação de texturas e modelos [Kevin e Andrew, 2004]. Estes e outros jogos digitais conseguiram tornar o ensino de programação mais acessível, mas nenhuma dessas abordagens possui uma estrutura do qual o jogador construa seu próprio cenário, com os elementos da sua escolha, e a partir disso, realizar a programação para dar movimentos aos elementos escolhidos de forma a concluir o objetivo do jogo. Esse diferencial é importante uma vez que o jogador tem um completo domínio sobre o seu jogo, mantendo assim a criança motivada e consequentemente, aprendendo mais sobre programação. 6. Conclusões Durante o XXIV Congresso da SBC (2004) em Salvador, o Grupo de Licenciatura em Computação (GT-3) aprovou, em assembleia, a proposta de incluir conteúdos da área de computação e informática no Ensino Médio [Pereira e et al. 2005], visando desde cedo desenvolver competências nessa área e também fomentar o interesse pela área aumentando o número de profissionais no país. A infraestrutura apresentada neste trabalho é um recurso indicado para ensinar programação para alunos do ensino médio, oferece várias possibilidades de desafios, sendo possível montar novos cenários e componentes para serem integrados com o 61 editor de programação. Permite, também, que cada aluno construa a seu tempo o conhecimento necessário para amadurecer a competência de desenvolver a programação do jogo. Agradecimentos Os autores agradecem a CAPES pela concessão das bolsas de pesquisa e pelo apoio financeiro para realização da mesma e a equipe do GamEdu Lab, em especial, os alunos Pedrina Brasil e André Soares. Referências Ceder, V.; Yergler, N. (2003) “Teaching Programming with Python and PyGame”. Apresentado na PyCon 2003. Grado, A.;; Tarouco, L. (2008) “O Uso de Jogos Educacionais do Tipo RPG na Educao”. In: Revista Novas Tecnologias na Educao – RENOTE, v. 6, n. 2, 2008. Kevin, B.;; Andrew, P. (2004). "The use of muppets in an introductory java programming course." In: ITE Information Technology Education Conference Larsen, F. N. (2013). "Robocode". Disponível em: <http://robocode.sourceforge.net/docs/ReadMe.html#what-is-robocode.> Acesso em: mar. 2013 Morati, P. B. (2003) “Por que utilizar jogos educativos no processo de ensino aprendizagem?” Rio de Janeiro: NCE/UFRJ. Disponível em: <http://www.nce.ufrj.br/ginape/publicacoes/trabalhos/PatrickMaterial/TrabfinalPatric k2003.pdf.> Acesso em: mar. 2013. Pereira J. J.; Rapkiewicz, C.E.; Delgado, C.; Xexeo, J.A.M. (2005) “Ensino de Algoritmos e Programação: Uma Experiência no Nvel Mdio”. XIII Workshop de Educao em Computao (WEI’2005). So Leopoldo, RS, Brasil. Prensky, M. (2002). "The motivation of gameplay: The real twenty-first century learning revolution." In: On the Horizon, 10(1):5–11., 2002 Resnick, M.;; Maloney, J.;; Monroy-Hernández, A.;; Rusk, N.;; Eastmond, E.;; Brennan, K.;; Millner, A.;; Rosenbaum, E.;; Silver, J.;; Silverman, B.;; Kafai, Y. (2009). "Scratch: programming for all." In: Commun. ACM, 52:60–67., 2009 Rewald, F. (2010) Escolas e estudantes desenvolvem games educativos. Folha de São Paulo, 11 jan. 2010. Disponível em: http://www1.folha.uol.com.br/folha/informatica/ult124u677394.shtml. Acesso em: 27 jan. 2010. Ribeiro, A.;; Coelho, A.;; Aguiar, A. (2012) "Jogo sério colaborativo para o ensino da programação a crianças". In: II Congresso Internacional TIC e Educação, 2012 62 Uma meta-ferramenta para apoio ao reuso na definição de processos de software padrão por organizações consultoras. Luiz Dourado Dias Junior1, Roberto Célio Limão1 1 Departamento de Engenharia Elétrica – Universidade Federal do Pará (UFPA) [email protected], [email protected] Projeto de Doutorado Ano de Ingresso: 2010 (previsão de conclusão em 2014) Programa de Pós-graduação em Engenharia Elétrica Resumo. Organizações de consultoria em processos de software têm se firmado no cenário nacional, em especial, no contexto do apoio à adesão de pequenas e médias empresas ao MPS.BR. Um dos momentos deste apoio está na definição de processos padrão, atividade considerada como sendo extremamente desafiadora. Este contexto, em especial, requer a habilidade das organizações para atenderem necessidades semelhantes de diversas empresas que precisam aderir aos padrões/modelos de qualidade, o que constitui excelente contexto para reuso de processos. A presente tese propõe avaliar a combinação entre uma base de ativos constituída a partir da experiência do grupo de pesquisa SPIDER e uma ferramenta de modelagem de processos na melhoria dos processos produzidos no contexto do projeto SPIDER. 1. Caracterização do Problema O desenvolvimento de software sem um processo definido é insustentável. Por outro lado, organizações com um processo maduro podem desenvolver software complexo de maneira previsível e controlável. Em um cenário de globalização, que acirra ainda mais a competitividade entre as organizações de software, a busca pela melhoria contínua dos processos de produção e de seus reflexos nos produtos (qualidade, satisfação do cliente) tem se mostrado cada vez mais importante e crítica para o sucesso das organizações [Ribeiro et al, 2011]. Neste contexto, destacam-se normas e modelos (referenciados no texto como padrões), que balizam a definição destes processos para seu uso pelas organizações, tais como: MPS.BR e CMMI (modelos); ISO/IEC 12207, ISO/IEC 20000, ISO/IEC 9126 (NBR 13596), ISO/IEC 12119 (normas). Estes padrões, tipicamente, definem capacidades que devem ser evidenciadas pelos processos empregados nas organizações que desenvolvem software. Desta forma, para conseguirem efetivamente definir processos que, em sua execução, evidenciem tais capacidades, os profissionais responsáveis precisam recorrer às suas experiências e às compartilhadas pela comunidade. Pois, conforme explicitam [Barreto & Murta & 63 Rocha, 2007] a tarefa é desafiadora, exigindo experiência e conhecimento de muitos aspectos da Engenharia de Software, dentre eles: características e necessidades das organizações, aderência a padrões, restrições de negócio, dentre outras. Em um cenário ainda mais complexo, [Barreto & Murta & Rocha, 2007] descrevem organizações que oferecem consultoria na definição, implantação ou na melhoria de processos de organizações de software. No Brasil, a atuação destas consultorias se tornou ainda mais relevante a partir do MPS. BR, visto que o mesmo reconhece e incentiva a atuação destas organizações. Ao longo desta atuação, as empresas consultoras tipicamente definem processos para múltiplas organizações de software que pleiteiam aderência a níveis de maturidade previstos nos modelos de qualidade (seja para fechamento de contratos ou para maior diferencial competitivo). A situação descrita configura uma excelente oportunidade de reuso de processos de software, pois, uma mesma empresa consultora precisa atuar junto a um conjunto de organizações de software com necessidades semelhantes. [Barreto & Murta & Rocha, 2007] apresentam uma proposta específica de reuso de processos para este contexto, com as seguintes características principais: tratamento de processos legados; abordagem de contextos multi-organizacionais; aderência às principais práticas do CMMI-DEV, MPS. BR e ISSO/15504. Entretanto, ainda há uma lacuna no que tange ao ferramental destinado a apoiar o reuso de ativos de processo por organizações de consultoria em contextos multiorganizacionais. É fato que considerável conhecimento venha sendo produzido e compartilhado, que a importância das organizações de consultoria venha sendo notável, e que a aderência de processos aos padrões de qualidade venha sendo um norteamento. Porém, mesmo neste cenário, as ferramentas tipicamente usadas por estas organizações não são amparadas por funcionalidades específicas que propiciem reuso de conhecimento disperso nos modelos de processos já criados pela organização, em especial, no que tange à escolha de ferramentas, que tipicamente estão sujeitas à restrições de custo, recursos para capacitação de equipe, políticas variadas (ex: adoção de software livre por organizações de desenvolvimento governamentais), dentre outras. Alguns trabalhos propõem metodologias para apoiar o reuso de processos de software, tais como: [Ribeiro et al, 2011] – abordagem baseada em uma arquitetura de processos de software; [Domíngues et al, 2008] – ambiente colaborativo para a melhoria de processos de software, baseado em um repositório de ativos, projetos e produtos. Outros trabalhos propuseram sistemas especialistas, para apoiar a implantação de modelos de qualidade em pequenas e médias empresas, dentre eles: [Eldrandaly 2008], [Adderley et al. 2010] e [da Silva et al. 2011]. Enquanto os primeiros abordam o reuso de ativos de processo, mas, não definem um ferramental adequado às organizações de consultoria em processos de software e não discutem o reuso de ferramentas, os segundos empregam inteligência computacional em soluções de apoio à implantação de processos em organizações, mas, não direcionam esforços às atividades de definição de processos e não se destinam aos consultores. Acredita-se que há pelo menos dois problemas relevantes para tratar, neste cenário: a) atender especificamente o contexto das organizações consultoras de processos de software que, tipicamente, atendem múltiplas organizações de software que necessitam aderir a padrões sólidos empregados pela indústria; b) o reuso de ativos 64 do tipo ferramenta, de modo a facilitar a seleção destas na definição de processos pelos consultores. Assim, entende-se que o desenvolvimento de sistemas baseados em conhecimento que favoreçam a constituição de bases de ativos de processo, especialmente, indexadas pelos resultados esperados para conformidade com os padrões, seja de grande relevância no apoio às atividades de definição de processos no contexto descrito. Conforme citado, a definição de processos de software é, tipicamente, orientada pelos resultados esperados especificados nos padrões de qualidade. Neste contexto, orientar a constituição da base de ativos pelos resultados esperados pode não só favorecer a reutilização de processos, mas, à redução de complexidade na definição de processos aderentes aos modelos de qualidade. E, por fim, defende-se que para auxiliar um consultor na escolha de ferramentas seja importante um mecanismo para representar as principais características dos ativos deste tipo, de modo que por similaridade com as ferramentas existentes na base de ativos, um consultor possa inferir se uma ferramenta não pertencente à base pode potencialmente auxiliar no alcance de um conjunto de resultados esperados do MPS.BR ou CMMI. Com base nestas premissas, a presente tese propõe: a) constituir uma base de ativos de processo indexada pelos resultados esperados do MPS. BR e CMMI; b) desenvolver uma ontologia de processos de software para orientar à incorporação de ativos na base de conhecimento; c) desenvolver uma ferramenta para manutenção desta base (denominada PMC); d) desenvolver um conjunto de extratores de ativos de processo de modelos definidos na SPIDER-PML; e) desenvolver um algoritmo para prospecção de ferramentas a partir de semelhança com as existentes na base de ativos. O objetivo de tais proposições é avaliar se o acréscimo destes mecanismos à atividade de definição de processos, realizada por aprendizes em consultoria de processos de software, os auxilia a produzir de modelos de processo mais aderentes aos padrões e normas de qualidade definidas no MPS.BR e CMMI. 2. Fundamentação Teórica Os principais aspectos teóricos que embasaram a proposta descrita neste trabalho são: a) mineração em repositórios de software; b) ontologias; c) sistemas de recomendação e; d) tecnologias de processos de software. As subseções descrevem as principais áreas de pesquisa que contribuíram para a construção desta proposta de tese. 2.1 - Minerações em Repositórios de Software A necessidade de melhoria nos processos decisórios nas organizações de software motivou o surgimento de uma área de pesquisa, denominada de mineração em repositórios de software (MSR) [Hassan, 2008]. A competitividade na indústria de software e a necessidade de maior produtividade e qualidade, tem levado ao emprego cada vez mais frequente, de algoritmos de mineração de dados no apoio às atividades de engenharia de software [Xie et al, 2009]. Neste contexto, a abundância de dados e a aplicabilidade prática destes algoritmos têm sido fatores relevantes ao crescimento da área. 65 2.2 - Ontologias e Linked Data Uma ontologia é uma especificação formal explícita de uma conceituação compartilhada: conceituação se refere a um modelo abstrato de algum fenômeno que identifica seus principais conceitos; explícita indica que os conceitos e suas restrições de uso são conhecidos; formal indica que uma ontologia pode ser lida por máquinas; e compartilhada indica que o conhecimento representado é consensual [Studer, 1998]. Por outro lado, Linked Data são conjuntos de datasets destinados a facilitar a integração de sistemas e o compartilhamento de conhecimentos na Web [Keivanloo, 2012]. Neste contexto, não são apenas datasets processáveis por máquinas, mas, com uma importância significativa no compartilhamento de conhecimento entre sistemas. 2.3 - Sistemas de Recomendação - RSEE RSSE são sistemas que proveem itens de informação valiosos à tomada de decisão, na realização de tarefas de engenharia de software [Robillard & Walker & Zimmermann, 2010]. Os referidos autores afirmam que esta classe de sistemas tem crescido nos últimos anos e que, em especial, alguns sistemas têm utilizado técnicas de MSR para construírem seus modelos de recomendação. Dada à diversidade de sistemas existentes, [Robillard & Walker & Zimmermann, 2010] consideram difícil generalizar um padrão arquitetural para RSSE, mas, identificam que a maioria dos sistemas nesta classe possui funcionalidades que envolvem pelo menos: a) coleta de dados: responsável por obter os dados a serem utilizados na construção do modelo de recomendação; b) motor de recomendação: para analisar os dados coletados e gerar recomendações; c) interface gráfica: para acionar o sistema de recomendação e apresentar os resultados. 2.4 - Tecnologias de Processos de Software - TPS Processos de software podem ser entendidos como um conjunto de atividades para a construção/manutenção/evolução de um software [Reis, 2003]. São descritos de maneira abstrata, por modelos que incluem vários tipos de informação: quem, quando, onde, como e por que certas atividades são realizadas [Reis, 2003]. Para facilitar a descrição de processos de software, diversas linguagens foram propostas. Neste contexto, é importante mencionar o esforço da OMG para definir uma linguagem genérica para o desenvolvimento de modelos de processo, denominada SPEM. Além da disponibilidade de linguagens de modelagem de processo, algumas ferramentas foram desenvolvidas para apoiar a atividade de modelagem, dentre elas: Eclipse Process Framework (EPF), Little-JIL, OpenUP, WebApsee e Spider-PM . 3. Contribuições Esperadas Dada à natureza do trabalho, espera-se que o mesmo possa contribuir principalmente com os seguintes aspectos: Fornecer um modelo formal para o domínio de definição de processos, por meio de ontologias; 66 Favorecer o desenvolvimento extensível da base de ativos, a partir do modelo conceitual formal definido pela ontologia de domínio de processos; Propiciar a reutilização sistemática de ativos de processo de software, bem como uma evolução controlada destes - a; Incentivar o emprego de técnicas de inteligência computacional (mineração de texto e repositórios de software, representação de conhecimento, raciocínio baseado em casos, dentre outros) no desenvolvimento de ferramentas de apoio à engenharia de software; Reduzir a complexidade da atividade de definição de processos de software, a partir da combinação de uma ferramenta de definição de processos (SPIDER-PM) com uma de reuso de ativos de processo (PMC – desenvolvida durante a tese); Apoiar a melhoria da formação de recursos humanos para atuação em consultoria em melhoria de processos de software, a partir da troca de experiência entre os alunos e o contato com a experiência de consultores explicitamente formalizada na base de ativos. 4. Estado Atual do Trabalho Atualmente, já foram desenvolvidos: a) ontologia de processos (baseada na linguagem SPIDER-PML); b) a ferramenta para extração de ativos de processo a partir dos modelos produzidos na SPIDER-PM; c) a ferramenta PMC para manutenção da base de ativos; d) um algoritmo híbrido (baseado em Cadeias de Markov, Naive Bayes e Similaridade de Palavras) para prospecção de ferramentas no que tange ao alcance dos resultados esperados de gestão de requisitos e projeto no MPS.BR. Em termos arquiteturais, a ferramenta é descrita a partir da visão de componentes, modelada com uso da linguagem UML e da ferramenta Astah Community. Figura 1 – Visão de Componentes 67 O diagrama de componentes da ferramenta é apresentado na Figura 1. Neste, podem-se perceber os seguintes componentes: a) pmc-assistant: ferramenta web de assistência ao consultor de implantação de modelos de qualidade de software, desenvolvida em linguagem Java e HTML; b) sambasore-ws: ferramenta que será usada para extrair ativos de processo de modelos definidos na linguagem SPIDER-PML; c) ontologias: ontologias de processo – contendo os conceitos e relações referentes às atividades, papéis, produtos de trabalho que estarão disponíveis para reuso na PMC; d) mongodb: banco de dados Nosql usado pelo sambasore-ws e pelo pmc-assistant para manutenção da base de ativos; e) fuseki: banco de dados de triplas, usado para armazenar na forma (sujeito, predicado, objeto) as instâncias da ontologia de domínio. 5. Comparação com Trabalhos Relacionados Abaixo segue um breve resumo e algumas comparações da presente proposta com os principais trabalhos relacionados, encontrados na literatura. Virtual Quality Editor – [Eldrandaly, 2008]: destinado a indivíduos, organizações e empresas de desenvolvimento de software que desejem implantar o ISO/IEC 90003 ou CMMI. Acompanha e sugere melhorias em processos do CMMI, a partir do diagnóstico destes processos no ambiente em que esteja operando; Diagnostic Intelligent Assistant – [Adderley et al. 2010]: pretende apoiar a implementação do modelo CMMI em pequenas e médias empresas. Trata-se de um SE, baseado em regras de produção formadas a partir da aquisição de conhecimento da organização (que pretenda implantar o CMMI), envolvendo seus objetivos organizacionais, riscos e pretensões de melhoria. Estes conhecimentos são usados para inferir áreas de processo a serem aprimoradas; Expert Mentoring - [da Silva et al. 2011]: SE proposto para auxiliar a dirimir dúvidas de interpretação dos resultados esperados das atividades de gestão de projetos e requisitos, no que tange ao preenchimento da planilha de indicadores (PI). A planilha é necessária à avaliação do MPS.BR e seu preenchimento tipicamente requer o apoio de um consultor MPS.BR; PIBOK-PB – [Domíngues et al, 2008]: framework colaborativo para melhoria de processos, baseado no reuso de seus ativos. Baseia-se em três repositórios (processos, projetos e produto) e em uma infraestrutura de colaboração que permite o compartilhamento de conhecimento. Apesar de serem bastante relevantes, percebe-se primeiramente que a maior parte dos trabalhos citados está focado no CMMI. Além disto, os trabalhos citados estão focados, primariamente, nas organizações produtoras de software. Um dos pontos originais desta tese é, justamente, enfocar o reuso de processos sob o ponto de vista das organizações consultoras com enfoque multi-organizacional. 68 O trabalho que apresenta uma abordagem mais semelhante ao proposto é o PIBOK-PB, pois, enfoca o reuso sob um ponto de vista colaborativo, entretanto, os atores envolvidos são diferentes: no referido trabalho, os principais colaboradores são os usuários dos processos ou outras organizações que queiram compartilhar conhecimento. Por outro lado, na abordagem desta tese o enfoque está centrado na colaboração entre os consultores de uma organização de consultoria, no contexto de definição e reuso de ativos de processo para múltiplas organizações. Além dos atores de colaboração, o PIBOK-PB está voltado para a instanciação de modelos de processo padrão e sua adaptação no momento da instanciação. Por outro lado, a abordagem desta tese foca primeiramente na tarefa inicial de definição de um processo padrão para uma ou mais organizações, tendo por objetivo facilitar este processo por meio de um ferramental apropriado para favorecer o reuso sistemático e, em especial, no que tange à escolha de ferramentas. 6. Avaliação dos Resultados No presente momento, o resultado do projeto é a primeira versão da ferramenta PMC, que será testada no mês de agosto pela equipe do projeto SPIDER. Posteriormente, os dados dos modelos de processo já construídos pelo projeto SPIDER deverão ser carregados na ferramenta para constituição da base inicial de ativos. Em meados do mês de outubro, a ferramenta será disponibilizada para um grupo de alunos de uma disciplina de processos de software, em nível de mestrado, os quais serão divididos em grupos para condução de um experimento de avaliação dos modelos de processo produzidos com e sem o apoio da ferramenta PMC. As variáveis que serão avaliadas no referido experimento ainda serão definidas, mas, pretende-se avaliar se há diferença significativa no grau de aderência ao MPS.BR/CMMI entre os modelos e processo produzidos com e sem apoio da PMC. Referências Adderley, T., Duggins, S., and Tsui, F. (2010). An examination of a rule-based expert system to aid in the implementation of the cmmi framework. In SEKE10, pages 5990–603. Barreto, A.; Murta, L.; Rocha, A. R. (2007) “Uma abordagem de definição de processo de software baseada em reutilização”. In: Workshop Anual de Melhoria de Processo de Software. Silva, L. M. O. da, de B. Paes, R., and de B. Costa, E. (2011). Expert mentoring: Assistente inteligente para esclarecimento de dúvidas sobre a determinação de evidências objetivas requeridas na avaliação MPS.BR. Domínguez, M. F., and Ramos, J. S. and Soto. A. M., and Esteban, A. S., and Segura, M. I. S. (2008). A Collaborative Framework to Support Software Process Improvement Based on the Reuse of Process Assets. ICSOFT 2008 - Proceedings of the Third International Conference on Software and Data Technologies, Volume PL/DPS/KE, Porto, Portugal, July 5-8, 2008 69 Hassan, A. (2008). The road ahead for mining software repositories. In Frontiers of Software Maintenance, 2008. FoSM 2008., pages 48–57. Keivanloo, I. (2012). Online sharing and integration of results from mining software repositories. In Software Engineering (ICSE), 2012 34th International Conference. Reis, C. L. (2003). Uma abordagem flexível para execução de processos de software evolutivos. Tese de Doutorado - PPGC - UFRGS. Robillard, M., Walker, R., and Zimmermann, T. (2010). Recommendation systems for software engineering. Software, IEEE, 27(4):80–86. Studer, R., Benjamins, V. R., and Fensel, D. (1998). Knowledge engineering: principles and methods. Data Knowl. Eng., 25(1-2):161–197. 70 Um Método de Avaliação da Qualidade do Modelo de Features em Linhas de Produtos de Software Baseado em Medidas* Carla I. M. Bezerra1,2, José Maria Monteiro1, Rossana M. C. Andrade1,† 1 Universidade Federal do Ceará (UFC), 1 Mestrado e Doutorado em Ciência da Computação (MDCC), Departamento de Computação (DC), Grupo de Redes, Engenharia de Software e Sistemas (GREat), Fortaleza, CE – Brasil 2 Campus Quixadá, CE – Brasil [email protected], {monteiro, rossana}@lia.ufc.br 1. Caracterização do Problema A avaliação da qualidade em uma Linha de Produtos de Software (LPS) apresenta uma complexidade maior do que no desenvolvimento de software tradicional. Este fato decorre de dois aspectos principais: i) produtos diferentes, em uma mesma LPS, podem requerer níveis de qualidade distintos, e ii) diversos produtos podem ser derivados de uma mesma LPS. Neste contexto, a avaliação da qualidade de todos os produtos de software de uma determinada linha mostra-se impraticável, tanto por razões econômicas quanto pelo esforço envolvido. Desta forma, novas estratégias capazes de reduzir o custo e o esforço gastos na avaliação da qualidade em LPSs são necessárias [Etxeberria e Sagardui 2008]. Uma estratégia que pode ser utilizada para reduzir os custos associados à garantia da qualidade das linhas de produtos de software consiste em realizar avaliações de qualidade nas fases iniciais da LPS, com o intuito de evitar que os erros se propaguem para outros artefatos da linha ou para fases posteriores. Um dos principais artefatos elaborados nas fases iniciais de uma LPS é o modelo de features. Este artefato é elaborado na fase de engenharia de domínio de uma LPS, sendo utilizado para modelar as partes comuns e variáveis entre os produtos que compõem uma família de produtos [Kang et al. 1990]. Como os modelos de features podem ser utilizados como uma plataforma para derivar muitas aplicações a partir de uma linha de produto de software, sua qualidade influencia as propriedades finais das aplicações desenvolvidas. Além disso, a manutenibilidade da linha está diretamente relacionada à modificação do modelo de features. Portanto, é importante assegurar a qualidade dos modelos de features já a partir dos estágios iniciais da linha. Alguns trabalho identificados focam na avaliação da qualidade do modelo de features em Linhas de Produtos de Software [Mendonça et al. 2009;; Bagheri e Gasevic 2011]. No entanto, esses trabalhos não fornecem um método de avaliação de qualidade consolidado. Estes trabalhos apenas consolidam um conjunto de medidas para avaliação * Este artigo é um resultado parcial do projeto UbiStructure com apoio do CNPq (MCT/CNPq 14/2011 - Universal) com o número 481417/2011-7 e do projeto Maximum da FUNCAP/FAPs/INRIA/INS2i-CNRS com o número 0064-000120100/12. † Bolsista do CNPq de Produtividade DT-2 com o número de processo 314021/2009-4 71 do modelo de features, não são baseados em características e atributos de qualidade relevantes no contexto da avaliação da qualidade do modelo de features em LPSs, e não fornecem uma especificação das medidas de forma a guiar a coleta e análise. Assim sendo, este trabalho tem como objetivo propor um método de avaliação de qualidade do modelo de features para LPSs baseado em medidas. O método proposto será formado por um conjunto de medidas e um processo para a coleta e análise dessas medidas. Adicionalmente, nós iremos investigar como o método proposto poderá ser utilizado e adaptado para LPSs específicas, como por exemplo, para LPS Sensíveis ao Contexto (LPSSC), que segundo Fernandes et al. (2011), são linhas de produtos que fornecem o suporte ao desenvolvimento de aplicações sensíveis ao contexto. O foco nesse tipo de linha se deve ao fato da complexidade e importância dos produtos a serem desenvolvidos. A computação sensível ao contexto está cada vez mais presente nas novas vidas de forma a fornecer, a partir do contexto informado, serviços adaptados e relevantes na realização de tarefas dos seus usuários. Existem muitos desafios inerentes ao desenvolvimento desse tipo de aplicação devido ao tratamento do contexto. Vale destacar que, até o presente momento, nós não identificamos na literatura métodos específicos para avaliar a qualidade dos modelos de features desse tipo de linha. 2. Fundamentação Teórica A avaliação da qualidade no contexto de linhas de produto de software é essencial, uma vez que um erro ou uma incompatibilidade em um ativo reutilizável pode ser propagado para um lote de produtos. Nesse sentido, a avaliação da qualidade em LPSs possui desafios que não estão presentes no desenvolvimento de software tradicional. Estes desafios são devido à variabilidade da LPS e pelo fato de os produtos gerados pela LPS poderem requerer diferentes níveis de qualidade [Etxeberria e Sagardui 2008]. A avaliação de produtos de software com o objetivo de satisfazer as necessidades de qualidade de software é um dos processos no ciclo de vida de desenvolvimento de software. A qualidade do produto de software pode ser avaliada medindo-se os atributos internos (tipicamente medidas estáticas de produtos intermediários), os atributos externos (tipicamente pela medição do comportamento do código quando executado) ou os atributos de qualidade em uso. O objetivo é que o produto tenha o efeito requerido num contexto de uso particular [ISO/IEC 9126 2003]. Em relação ao estabelecimento de medidas para a avaliação da qualidade, o padrão IEEE (1998) define uma metodologia para estabelecer os requisitos de qualidade, além de identificar, implementar, analisar e validar processos e medidas de qualidade voltados para produtos de software. As medidas são essenciais na avaliação da qualidade de um produto, e estas podem compor um modelo de qualidade. Segundo a norma SQuaRE [ISO/IEC 25000 2005], um modelo de qualidade é composto de características de qualidade, subcaracterísticas e atributos. Característica de qualidade é um conjunto de propriedades de um produto de software pela qual sua qualidade pode ser definida e avaliada [ISO/IEC 9126 2001]. Uma característica pode ser dividida em várias subcaracterísticas. Atributos são propriedades mensuráveis, físicas ou abstratas, de uma entidade. As medidas de qualidade devem estar alinhadas as características e/ou subcaracterísticas de qualidade em um produto de software. Para derivar as medidas que realmente reflitam os atributos de qualidade da linha pode-se utilizar do paradigma GQM (Goal Question Metric). O GQM representa uma 72 abordagem sistemática para a adaptação e integração de objetivos para os modelos dos processos de software, produtos e perspectivas de interesse de qualidade, com base nas necessidades específicas do projeto e da organização [Basili et al. 1994]. Em relação a técnicas de avaliação de qualidade para Linhas de Produto de Software, Etxeberria e Sagardui (2005) classifica essas técnicas em dois grupos: Técnicas de Questionários para Avaliação Qualitativa: incluem cenários, questionários e checklists. Podem ser usadas para avaliar a qualidade de desenvolvimento ou operacional;; Técnicas de Medição para Avaliação Quantitativa: incluem simulação, prototipagem, modelos matemáticos e experimentais. Podem ser usadas para medir a aplicação de técnicas que englobam qualidades específicas, normalmente operacionais. Segundo Etxeberria e Sagardui (2008), a avaliação de qualidade pode ser realizada em diferentes fases: nas fases iniciais, relacionadas à engenharia de domínio, como por exemplo, a fase de design (métodos de avaliação de arquitetura de software), ou em fases relacionadas à engenharia de aplicação (métodos de medição de qualidade). Para reduzir custos e aumentar a qualidade dos outros artefatos e dos produtos da LPS, a avaliação de qualidade deveria ser aplicada em fases iniciais, na Engenharia de Domínio. Muitos trabalhos têm investigado a avaliação de qualidade da arquitetura da LPS, mas pouco se tem pesquisado acerca da da qualidade do modelo de features. O modelo de features é um modelo de alto nível utilizado para expressar os produtos da LPS, representando as features de um domínio específico, suas semelhanças, variabilidades e relações. Já uma feature é um atributo, qualidade ou aspecto visível ao usuário [Kang et al. 1990]. Existem vários tipos de notações propostas para o modelo de features, dentre elas podem se destacar o Feature-Oriented Domain Analysis (FODA) [Kang et al. 1990], o Feature-Oriented Reuse Method (FORM) [Kang et al. 1998], o Feature Reuse-Driven Software Engineering Business (Fe-atuRSEB) [Griss et al. 1998]. No método FODA, um modelo é composto de dois elementos: features e relacionamentos entre essas features. A avaliação da qualidade do modelo de features influência diretamente a qualidade dos produtos derivados da LPS. A avaliação do modelo de features pode também contribuir para a qualidade da manutenção das LPSs em evolução. Muitos trabalhos estão focados na verificação da consistência do modelo de features. Algumas medidas para avaliação da consistência e corretude do modelo também irão ser utilizadas nesse trabalho, como número de features mortas, features comuns, número de configurações válidas, etc [Bezerra et al. 2012]. Nesse trabalho, iremos focar apenas na avaliação de medidas de qualidade do modelo de features. Existem outros tipos de linhas de produto, como as Linhas de Produtos de Software Sensíveis ao Contexto (LPSSCs), em que a avaliação da qualidade pode se diferenciar, pois às mesmas medidas de um modelo de feature de uma linha tradicional pode não avaliar a qualidade inerente ao contexto. Uma LPSSCs é uma linha de produtos que apoia o desenvolvimento de produtos sensíveis ao contexto. LPSSC capturam tanto similaridades quanto variabilidades das aplicações, assim como informações do ambiente do contexto que podem influenciar nos produtos gerados [Fernandes et al. 2011]. 73 3. Objetivo e Contribuições O presente trabalho tem por objetivo desenvolver um método para avaliação do modelo de features em LPSs para auxiliar a identificação e correção de erros em fases iniciais da linha e na sua manutenção. O método irá conter um processo para executar a avaliação e um conjunto de medidas com especificação de coleta e análise. A nossa principal contribuição é, portanto, avaliar a qualidade de LPSs em estágios iniciais, evitando que os erros sejam propagados para os artefatos da linha de forma a evitar defeitos nos produtos gerados. Também é pretendido permitir a evolução da linha melhorando sua manutenção como consequência da avaliação do modelo de features. 4. Estado Atual do Trabalho A execução deste trabalho está dividida em 5 fases: (i) identificar modelos de avaliação de qualidade do modelo de features em LPSs;; (ii) identificar, definir e especificar medidas para avaliação do modelo de features em LPSs;; (iii) definir a notação do modelo de features que o método de avaliação vai utilizar;; (iv) definir um método de avaliação do modelo de features em LPSs;; (v) investigar como o método proposto poderá ser utilizado e adaptado para LPS Sensíveis ao Contexto (LPSSC);; e, por último, (vi) validar o método de avaliação proposto utilizando modelos de features de LPSs completas e já utilizadas pela academia ou indústria. Durante a execução da fase (i) já realizamos uma revisão bibliográfica com o objetivo de identificar métodos de avaliação da qualidade do artefato modelo de features. Nesta revisão [Bezerra et al. 2013] não foram encontrados métodos voltados para a avaliação da qualidade do modelo de features. Isso é confirmado especialmente pela revisão sistemática sobre avaliação de qualidade em Linhas de Produtos de Softwares realizada por Montagud e Abrahão (2009a). Apenas iniciativas individuais de elaboração de medidas voltadas para a avaliação de alguns aspectos do modelo de features, sem ter um modelo formal de apoio [Montagud and Abrahão 2011;; Bagheri e Gasevic 2011], foram observadas. Para a realização da fase (ii) deste trabalho, realizou-se uma ampla revisão bibliográfica, a partir da qual foi possível identificar, definir e especificar medidas para avaliação do modelo de features em LPSs. Em seguida, as medidas propostas foram validadas utilizando-se uma LPS real. Maiores detalhes sobre a execução dessa etapa do trabalho são apresentados em Bezerra et al. (2013). No entanto, ainda estão sendo identificados outros fatores que podem afetar a qualidade do modelo de features, de forma a influenciar outros artefatos e dificultar a manutenção da linha. A partir da identificação de fatores que afetam a qualidade do modelo de features, serão derivadas outras medidas utilizando o modelo GQM para complementação do conjunto de medidas que irá compor o método a ser proposto. A notação para avaliação do modelo também foi escolhida, concluindo a etapa (iii). A notação utilizada para representar o modelo de features será a mesma utilizada no método FODA (Feature-Oriented Domain Analysis), proposto por Kang et al. (1990), devido à sua ampla utilização. A notação do modelo de features utilizada no método FODA, representa similaridades e variabilidades dos produtos que compõe a LPS. O método proposto será formado por um conjunto de medidas genéricas e um processo para a coleta e análise dessas medidas. No entanto, pretende-se definir medidas 74 que também cubram a qualidade de outros tipos de linhas como as LPSSCs. Para LPSSCs a notação do método FODA não representa o contexto. Para isso, será utilizada a notação do modelo de features definida por Fernandes et al. (2011). A etapa (iv) foi definida parcialmente. Na etapa (iv) será definido um método com o objetivo de definir o processo de avaliação da qualidade do modelo de features utilizando as medidas anteriormente definidas, dispostas em uma especificação de medição. A Figura 1 apresenta os passos do método de avaliação de qualidade. B B1 Especificação de Medidas INÍCIO B2 B2 B Features Modelo Atual Medir Modelo Atual B1 Evoluir Modelo Atual Especificação de Medidas Medir Modelo Evoluído Comparar Medições Relatório de Medidas Relatório de Medidas FIM B Relatório de Medidas A B1 B2 Modelo Evoluído Versão 1 Figura 1: Etapas e artefatos do método de avaliação de qualidade do modelo de features. As etapas do modelo são descritos a seguir: (a) Medir o Modelo de Features Atual: nessa fase o modelo de features deve ser já existente na linha de produto. De posse a uma especificação de medidas que será pré-definida neste trabalho, o engenheiro de domínio irá realizar medições no modelo de features atual, visando avaliar os dados atuais do modelo. Os dados deverão ser registrados pelo Engenheiro de Domínio no Relatório de Medidas para comparações futuras. O Relatório de Medidas também será pré-definido neste trabalho com base nas especificações de Medições;; (b) Evoluir o Modelo Atual: a partir de alguma necessidade de alteração, exclusão ou inclusão de features no modelo, o Engenheiro de Domínio deverá evoluir a linha de acordo com as novas necessidades;; (c) Medir o Modelo Evoluído: de posse do modelo evoluído pelo Engenheiro, este deverá aplicar as mesmas medidas do modelo de features atual no modelo de features evoluído, de acordo com a Especificação de Medidas. Os dados deverão ser registrados no Relatório de Medidas;; (d) Comparar Medições: com base nos dados coletados das medidas no modelo de features atual e o modelo de features evoluído, este deverá analisar os dados e verificar se as medidas coletadas no modelo de features evoluído é igual ou melhor do que as medidas coletadas no modelo atual. O foco do método de qualidade proposto é apenas na avaliação da qualidade, não faz parte do escopo as melhorias a serem incorporadas para evolução do modelo de features. As etapas (v) e (vi) não foram executadas. O método proposto será validado na etapa (vi) utilizando LPSs completas e já utilizadas pela academia ou indústria. Para isso será realizada uma análise quantitativa dos resultados das medidas propostas e uma análise qualitativa referente à execução do método proposto [Wholin et al. 2012]. 5. Trabalhos Relacionados Poucas pesquisas têm sido desenvolvidas com o objetivo de assegurar a qualidade de linhas de produtos de software. Abaixo são citados alguns trabalhos que focam na avaliação de qualidade das LPSs. 75 Montagud e Abrahão (2009) apresenta um método de avaliação de qualidade baseado no SQuaRE [ISO/IEC 25000 2005]. Este trabalho define medidas para avaliação de todas as fases da LPS, mapeando-as com características de qualidade e atributos de qualidade de acordo com a norma de qualidade SQuaRE. Adicionalmente, define-se como esse método de avaliação deve ser aplicado. No entanto, esse método não está direcionado para a avaliação do modelo de features, e também não foca na evolução da LPS. Bagheri e Gasevic (2011) propõem um conjunto de medidas estruturais para modelos de features de linhas de produtos de software e valida essas medidas utilizando princípios teóricos. Neste trabalho é realizada uma investigação por meio de uma experimentação controlada de forma a analisar se estas medidas estruturais podem ser bons indicadores (indicadores precoces) das três subcaracterísticas principais de manutenção: analisabilidade, mutabilidade e compreensibilidade. No entanto, foi verificado que o trabalho não possui uma especificação completa para essas medidas, contendo apenas uma breve descrição das medidas, além de um estudo sobre a coleta das medidas propostas. Em Mendonça et al. (2009) é apresentada a ferramenta SPLOT, um sistema web com interfaces para configuração e recomendação de linhas de produtos de software a partir do modelo de features. A ferramenta apresenta também um repositório de modelos de features com mais de 300 modelos, o que facilita o compartilhamento de modelos de features entre os pesquisadores da área. Dessa forma, a partir dos modelos de features que podem ser selecionados é possível obter dados de análises desses modelos, os quais são calculados de forma automática pela ferramenta. A ferramenta possibilita a extração de algumas medidas para avaliação do modelo de features. No entanto, estas medidas não possuem especificações de cálculo, coleta e análise. Além disso, o conjunto de medidas não é completo não sendo foco da ferramenta a avaliação da qualidade do modelo de features. 6. Metodologia de Avaliação dos Resultados A validação do método proposto irá utilizar LPSs completas e já utilizadas pela academia ou indústria. Serão coletados os dados quantitativos dos resultados das medidas que compõem o método de avaliação proposto neste trabalho para a avaliação do modelo de features. Conforme apresentado na seção 4, na Figura 1, os resultados serão coletados do modelo atual de um modelo de features, e da evolução desse modelo, para avaliação da qualidade. Esses resultados serão avaliados com ferramentas estatísticas de modo a identificar correlação entre as medidas e outros fatores como a manutenibilidade, que podem indicar a qualidade ou não dos modelos de features. Por fim, pretende-se validar o método de avaliação propostos por meio de uma avaliação qualitativa [Wholin et al. 2012]. Referências Bagheri, E.;; Gasevic, D. (2011) “Assessing the maintainability of software product line feature models using structural metrics”. Software Quality Journal, 2011 – Springer. Basili, V. R.;; Caldiera, C.;; Rombach, H. D. (1994) “Goal Question Metric Paradigm. Encyclopedia of Software Engineering”. John Wiley & Sons, pp. 528-532. 76 Bezerra, C. I. M.;; Monteiro, J. M.;; Andrade, R. M. C. (2013) “Avaliação da Qualidade do Modelo de Features em Linhas de Produtos de Software Utilizando Medidas”. XII SBQS - Simpósio Brasileiro de Qualidade de Software, Salvador, BA (artigo aceito). Etxeberria, L. e Sagardui, G. (2005) “Product-line architecture: New issues for evaluation”. In J. H. Obbink and K. Pohl, editors, 9th International Conference on Software Product Lines, SPLC, Proceedings, volume 3714 of Lectures Notes in Computer Science, pages 174–185. Springer. Etxeberria, L. e Sagardui, G. (2008) “Variability Driven Quality Evaluation in Software Product Lines”, in Proceedings of 12th International Software Product Line Conference, pp. 243-252. Fernandes, P.;; Werner, C.;; Teixeira, E. (2011) “An Approach for Feature Modeling of Context-Aware Software Product Line”. In Journal of Universal Computer Science, v. 17, n. 5, mar, p. 807-829. Griss, M. L.;; Favaro, J.;; Alessandro, M. D. (1998) “Integrating feature modeling with the rseb”. In: Proceedings of the 5th International Conference on Software Reuse. Washington, DC, USA: IEEE Computer Society, 1998. (ICSR '98). IEEE Standard for a Software Quality Metrics Methodology IEEE Std. 1061- 1998. ISO/IEC 9126-1 International Standard: Software engineering - Product quality. Part 1: Quality model, 2003. ISO / IEC 25000: 2005. Software Engineering. Software product Quality Requirements and Evaluation (SQuaRE). Kang, K. C.;; Cohen, S. G.;; Hess, J. A.;; Novak, W. E. e Peterson, A. S. (1990) “Feature- Oriented Domain Analysis (FODA) Feasibility Study,” Carnegie-Mellon University Software Engineering Institute, Tech. Rep. Kang, K. et al. (1998) “Form: A feature-oriented reuse method with domain-specic reference architectures”. Annals of Software Engineering, Springer Netherlands, v. 5, p. 143. Mendonca, M., Branco, M. e Cowan, D. (2009) “S.P.L.O.T. - Software Product Lines Online Tools”. In Companion to the 24th ACM SIGPLAN International Conference on Object-Oriented Programming, Systems, Languages, and Applications, OOPSLA, Orlando, Florida, USA Montagud, S.;; Abrahão, S. (2009). “A SQuaRE-bassed quality evaluation method for software product lines”. Master’s thesis, December 2009 (in Spanish). Montagud, S.;; Abrahão, S. e Insfran, E. (2011) “A systematic review of quality attributes and measures for software product lines”. Software Quality Journal, 2011 – Springer. Tessier, P.;; Gérard, S.;; Terrier, F. e Geib, J. (2005) ‘‘Using variation propagation for model-driven management of a system family.’’ In Software Product Lines, pp. 222– 233. Wohlin, C., Runeson, P., Höst, M., Ohlsson, M.C., Regnell, B., Wesslén, A. (2012) “Experimentation in Software Engineering”. Springer, 2a edição, 2012, XXIII, 236 p. 77 Mining Product Risks to Support Risk-based Testing Aluna Ellen Polliana Ramos Souza Orientador Prof. Adriano Lorena Inácio de Oliveira Co-orientadora Profª. Cristine Martins Gomes de Gusmão Pós graduação em Ciência da Computação - Centro de Informática (CIn) Universidade Federal de Pernambuco (UFPE) – Pernambuco, PE – Brasil {eprs,alio}@cin.ufpe.br Nível: Doutorado Ano de Ingresso: fevereiro de 2012 Previsão de Conclusão: janeiro de 2016 Aprovação da Proposta: não qualificado Evento: SBES Abstract. Background: Risk-based Testing (RBT) consists of a set of activities regarding the identification of risk factors related to software requirements. Once identified, the risks are prioritized according to their likelihood and impact. Test cases are designed based on the strategies for treatment of risk factors and software testing efforts are continuously adjusted according to risk monitoring. Therefore, RBT allows identifying the software requirements that have higher probability of failing so testing resources can be more precise. Although studies show the efficiency of the RBT approach, test engineers still find difficulties in its application and this occurs because risk management activities are abstract and need training to be applied. Aim: The proposition of this Thesis is guided by the use of machine learning techniques to identify risks factors related to software requirements in order to semi automate the risk identification activity. Method: Text mining and natural language processing techniques combined with ontologies are used to discover risk factors in software requirement specifications. The identified risks are classified according to Software Engineering Institute (SEI) taxonomy. The results are measured through precision, recall and f-measure metrics. Expected Results: Considering text mining limitations, such as the possibility of producing inaccurate results, this work does not have the goal to completely replace the human-based risk identification, but to test the hypothesis that text mining results improved the quality of the risk analyst activity. Finally, it is expected that, by improving the use of testing resources through reduction of effort, time and cost, the software product quality will be augmented. Palavras-chave. Software Testing, Risk-based Testing, Text Mining, Product Risks 78 1. INTRODUCTION Even with the adoption of new technologies, process models, techniques, methods and tools, most of the developed systems still have delays in development, leading to costs and functionalities beyond expectations due to unmanaged risks. According to Goldsmith (2006), testing is our primary way of controlling system and software risks. Therefore, the Software Engineering Body of Knowledge (SWEBOK) [Abran et al., 2004], section on testing, states that testing must be driven based on risk; i.e. testing can also be seen as a risk management strategy. However, in the delivery of software products, the testing activity commonly does not receive the appropriate attention, especially because of time, resources and cost restrictions. Also, the cost involved with testing, generally takes more than forty percent of the initial value of the software under development. In this sense, RBT approach emerges as a proposal to minimize some problems with software testing. Conducted correctly, RBT enables better use of available time and resources and ensures that the most important work is completed and that any tests that are skipped or shortchanged are of minor importance [Goldsmith, 2006]. Currently software testing approaches perform “risk based testing” in an ad hoc way [Amland, 1999; Bach, 1999], where it is not possible to identify, evaluate and control the risks related to software requirements. Because of this, the American consultant James Bach, in 1995, proposed the term “Risk-based Testing” to define the processes, approaches and techniques of software testing that are explicitly guided by risks [Goldsmith, 2006]. Despite studies [Amland, 1999; Souza et al., 2010; Chen, 2002] proving the efficiency of the RBT approach, test engineers still find difficulties in its application and this occurs because risk management activities are abstract and require specialized skills not usually performed by test engineers [Goldsmith, 2006] . Also, most of techniques and tools for risk identification and analysis require a great amount of manual effort and use subjective inputs from domain experts and/or system analysts, making the RBT approach infeasible for software products with a high number of functionalities. In this context, techniques that allow automation of repetitive tasks, such as machine learning, are being applied to software engineering. So, through natural language processing and text mining application, this thesis proposal aims to identify product risk associated with the software requirements in order to support the RBT approach. More specifically, this work has a goal of semi automating the risk identification activity. This document is organized as follows: after this introductory section, where a general explanation about the problems that motivates the execution of this work is given, a section of theoretical foundation is presented which gives an overview of the RBT and text mining approaches. Subsequently, the solution proposed by this thesis is described. Section 4 presents the methodology and current state of the work. Section 5 lists some related work and, finally, the expected contributions and evaluation section is stated. 79 2. THEORETICAL FOUNDATION In this section, the fundamental concepts and state of the art of the risk-based testing and text mining approaches are presented. 2.1 Risk-based testing approach Analyzing several RBT approaches in the literature, three different stages of the riskbased test process were identified and are hereafter described: First stage: consists of the identification and analysis of product risks associated to software requirements to produce a prioritized list of risks. The identification is performed by a revision of software functionalities or requirements looking for flaws in the functionality that may cause failure. After that, functionalities are prioritized to test execution through a risk analysis, where indicators of occurrence probability and impact are evaluated to determine the risk exposure for all functionalities. Second stage: test cases are designed to mitigate the identified risks on the previous stage. A risk is mitigated when the test cases designed to it are successfully executed. When a test case is executed and fails it means that the risk associated to that test case still exists. In other words, it was not mitigated. Third stage: comprises the follow-up and control of risks. As soon as a risk is eliminated, a new one arises and test efforts must be adjusted in order to always focus on the most important risks, that is, focus on the functionalities that need to be better tested. For the follow-up and risk control, some specific indicators for the RBT approach are given by [Amland, 1999; Souza et al., 2009]. 2.2 Text mining According to recent studies, about 85-90% of corporate data are stored in non-structured ways, most of them in text format [Delen and Crossland, 2008]. With respect to software engineering, a large number of companies keep history of project data which were previously developed but the extraction of relevant information is difficult due to the high amount of data. This explains the reason for the growth and the importance of text mining researches in this area. Text mining, also known as Knowledge Discovery from Text (KDT), is the technology which discovers patterns and trends or knowledge from huge collections of unstructured text. It is based on technologies like: Natural Language Processing (NLP), Information Retrieval, Information Extraction, Data Mining and, more recently, Ontologies which helps to bridge the ambiguity of the natural language when expressing notions and their computational representation in a formal language. The primary focus of text mining is classification and prediction. Given a sample of past experience and correct answers for each example, the objective is to find the correct answers for new examples [Weiss et al. 2005]. Unsupervised approaches such as clustering are also applied. Measures of accuracy like “recall” and “precision” are especially used in text mining. 80 3. PROPOSED APPROACH Figure 1 presents the steps of the knowledge extraction process from text, including areas of use in RBT. Through NLP and ontological annotation the software information is extracted from software requirement specification, structured and text mining techniques are applied to discover risks to support the RBT activities. The approach is divided into three main steps and is fully described hereafter. Figure 1. Knowledge extraction process from software engineering artefacts 3.1 Text processing This step is responsible for the information extraction and manipulation in order to convert it into a structured form. The information extraction systems analyze unrestricted data in order to extract information about pre-specified types of events, entities or relationships. Techniques like key-words and searching by similarity are used, as well as lexical analysis, stopwords removal, stemming, key-terms selection, weight determination and ontological annotation. Finally, ontology is populated with the requirement information. Ontology is a commonly used technique for knowledge representation [Witte et al., 2008]. The text mining system for populating the software requirement ontology under construction is based on GATE - General Architecture for Text Engineering tool [Cunningham et al., 2011], which is a widely used open source framework for text processing developed and maintained by the University of Sheffield since 1995. 3.2 Data mining This step is responsible for knowledge discovering in structured data bases. Data to be mined must go through a preparation process, that changes according to a chosen mining algorithm. It also includes the creation of mining models, samples definition and selection of data to train the created model. After data preparation, statistical, mathematical and/or computational techniques are applied to knowledge extraction. As shown in Figure 2, the product risks are identified and classified for each one of sentence or use case flow specified in the software requirement artefact. The risk and the requirement sentence are the inputs to train the model. The goal is to classify each requirement sentence (use case flow or scenario) into one of the risk categories of SEI Requirement class. So, when a new requirement is presented, it is classified into one of the risk categories. The risks are identified using a Taxonomy Based Questionnaire (TBQ) proposed by the Software Engineering Institute (SEI). The software development team answer 81 some questions and, according to their answers, a risk may be associated or not to a requirement. The motivation to use TBQ in the risk identification is that the team does not need to have knowledge about risk management. In the TBQ, the risks are automatically classified followed by SEI risk taxonomy [Carr et al., 1993] that organizes the risks involved in the software development process according to their origin, as shown in Figure 3. Figure 2. Risk identification from software requirement document The Product Engineering class contains problems in the product related to technical actions. These are also known as product or technical risks and affect the quality and/or performance of the software being developed. The elements composing this class are: Requirements, Design, Code and Unit Test, Integration and Test and Engineering Specialties. This work treats the Requirement class that contains the risks related to Stability, Completeness, Clarity, Validity, Feasibility, Precedent and Scale. Software Development Risk Product Engineering CLASS ELEMENT ATTRIBUTE Stability Requirement Completeness Design Validity Development Environment Program Constraints Other elements Other attributes Figure 3. SEI Software risk classification [Carr et al., 1993] Initially, the Naive Bayes classifier will be used because it is based on supervised learning and requires a small amount of training data. Afterwards, with a larger sample training data, other supervised algorithms will be used in combination with unsupervised approaches. The “precision”, “recall” and “f-measure” metrics are used to evaluate the results together with empirical studies execution. 3.3 Risk-based testing The RBTProcess – Risk-based Software Testing Process model [Souza and Gusmão, 2008] will be updated to include the automated risk identification step, as well as new functionalities will be added to the RBTTool - CASE tool for RBT approach [Venâncio et al., 2009]. 82 4. METHODOLOGY AND PROGRESS The methodology of this work is based on Figure 1 and divided into six stages presented in Table 1. The efforts are now concentrated on the first and second stages where a systematic literature review was made with the goal to identify, evaluate and interpret evidences of use of natural language processing techniques applied to text mining in primary studies from the last ten years. Also, systematic mapping of literature is being executed to map primary studies that describe text mining uses in software engineering and software management. In parallel, tools for text processing were evaluated and GATE [Cunningham et al., 2011] was selected as it met most requirements for a text mining system and it is open source. According to D’Aquin and Noy (2012), it is more cost-effective for data providers to reuse existing, preferably well-established and well-tested ontologies to describe their data, rather than to develop ontologies from scratch. In this sense, a survey of software requirement ontologies was performed and two ontologies [Jureta et al., 2008; Verma and Kass, 2008] are being studied to build a new one that meets the needs of this approach. For the text processing stage, a case study is starting in the second semester in a research project that builds mobile applications. For all software development iteration, the team will perform manual risk identification using the TBQ, as explained in section 3.2 Data mining. The resulted data of manual risk identification will be used to train the data mining model. Following the lessons learned from [Port et al., 2011], a pilot is built with only three of the product risk classes presented in Figure 3, a simple supervised learning algorithm and small data set will be used before jumping in to a full analysis. Table 1. Thesis progress 2012 1º 2º Activities/Period 2013 1º 2º 2014 1º 2º 2015 1º 2º 1. Initial study and program courses 2. Text processing 3. Data mining 4. Risk-based testing 5. Case study and experimentation 6. Thesis writing 5. COMPARISON WITH RELATED WORK Port and other authors (2011) propose an approach that identify defective requirements more effectively. The authors combined text mining and natural language processing to discriminate between temporal and non-temporal requirements. The authors are also investigating text mining and natural language processing for identifying ambiguous and inconsistent requirements, differently from this proposal of thesis that has the goal of identifying product risks associated to stability, completeness, clarity, validity, feasibility, precedent and scale. Other software engineering activities have also been addressed by text mining, for example: software reverse engineering [Maletic and Marcus, 2000], software engineering artefacts traceability [Huang et al., 2010; Port et al., 2011; Poshyvanyk et al., 2006; Hayes et al., 2006; Lormans and Van Deursen, 2006; Duan and Cleland- 83 Huang, 2007], association rules from source code [Michail, 2000; Li and Zhou, 2005; Livshits and Zimmermann, 2005; Engler et al., 2001], predicting the frequency and severity of defects and measurable attributes for verification and validation [Menzies et al., 2008]. 6. EXPECTED CONTRIBUTIONS AND EVALUATION This thesis proposal aims to mine risks from software requirement documents. The identified risks are classified according to SEI risk taxonomy. The nature of this kind of document is that they are often inconsistent, incomplete, ambiguous and domain dependent. The main challenge of this work is whether it is possible to build rules and patterns from text with the mentioned features. We do not know the software requirement maturity level needed to extract risk information. Considering text mining limitations, such as the possibility of producing inaccurate results [Huffman et al., 2005; Shi and Kong, 2009; Port et al., 2011], this work does not have as its goal to completely replace human-based risk identification, but to test the hypothesis that text mining results improved the quality of the risk analyst activity. In this sense, empirical studies need to be performed to examine the impact of analyst decisions on the final outcome by looking for evidence which suggests that using the text mining approach: (i) more “valid” risks are identified (precision); (ii) the time spent on risk management activities is reduced and (iii) less “false” risks are identified (recall).It is also intended to discover the patterns of analyst behavior when working with the results of text mining tools during the RBT lifecycle and to establish the factors that affect it and the nature of their effects. REFERENCES A. Abran, J.W. Moore, P. Bourque, R. Dupuis, (Editors). “Guide to the Software Engineering Body of Knowledge” (2004 Version). IEEE Computer Society, ISBN 0-7695-2330-7, 2004. S. Amland, “Risk Based Testing and Metrics: Risk analysis fundamentals and metrics for software testing” in 5th International Conference EuroSTAR’99, 1999. M. J. Carr, S.L. Konda, I. Monarch, F. C. Ulrich, C. Walker, “Taxonomy Based Risk Identification” Technical Report CMU/SEI-93-TR-6. SEI, Carnegie Mellon University, 1993. Y. Chen, “Specification-based Regression Testing Measurement with Risk Analysis.” Master Theis, University of Ottawa, 2002. H. Cunningham, et al. Text Processing with GATE (Version 6). University of Sheffield Department of Computer Science. ISBN 0956599311, 2011. D. Delen, M.D. Crossland, “Seeding the survey and analysis of research literature with text mining”. Expert Systems with Applications, v. 34, n.3, 2008. C. Duan, J. Cleland-Huang, “Clustering support for automated tracing”, In Proceedings of the 22 IEEE/ACM international Conference on Automated Software Engineering, Page 244-253, Atlanta, Georgia, USA, 2007. D. Engler, D. Y. Chen, S. Hallem, A. Chou, B. Chelf, “Bugs as deviant behavior: a general approach to inferring errors in systems code”, in SOSP, pages 57–72, 2001. R. Goldsmith, “Early and Effective: The Perks of Risk-based Testing”. In: Software Test and Performance Magazine, v.3, p.24-30, 2006. 84 J. H. Hayes, A. Dekhtyar, S. K. Sundaram, “Advancing candidate link generation for requirements tracing: the study of methods”, in IEEE Trans. on Software Engineering, vol.32,no.1, pp 4-19, January 2006. L. Huang, D. Port, L. Wang, T. Xie, T. Menzies, “Text Mining in Supporting Software Systems Risk Assurance” in ASE’10, September 20-24, Antwerp, Belgium, 2010. J. Huffman, A. Dekhtyar, S. Sundaram, “Text Mining for Software Engineering: How Analyst Feedback Impacts Final Results”, in MSR, pp. 58-62, 2005. I. Jureta, J. Mylopoulos, S. Faulkner. Revisiting the Core Ontology and Problem in Requirements Engineering. 2008 16th IEEE International Requirements Engineering Conference, 71–80, 2008. Z. Li, Y. Zhou, “PR-Miner: Automatically extracting implicit programming rules and detecting violations in large software codes”, in ESEC/FSE, pages 306–315, 2005. V. B. Livshits, T. Zimmermann, “DynaMine: Finding common error patterns by mining software revision histories”, in ESEC/FSE, pages 296–305, 2005. M. Lormans, A. Van Deursen, “Can LSI help Reconstructing Requirements Traceability in Design and Test?”, in 10th IEEE European Conf. on Software Maintenance and Reengineering, pp. 47-56, 2006. J. I. Maletic, A. Marcus, “Using latent semantic analysis to identify similarities in source code to support program understanding”, in 12th IEEE International Conference on Tools with Artificial Intelligence (ICTAI’00), p 46, 2000. T. Menzies, M. Benson, K. Costello, C. Moats, M. Northey, J. Richardson, “Learning Better IV&V Practices,” in Systems and Software Engineering, Springer London, 4(2), 169-183, 2008. A. Michail, “Data mining library reuse patterns using generalized association rules” in ICSE, pp.167–176, 2000. D. Port, A. Nikora, J. Hihn, L. Huang, “Experiences with Text Mining Large Collections of Unstructured Systems Development Artefacts at JPL”, in ICSE, 2011. D. Poshyvanyk, Y.G. Gueheneuc, A. Marcus, G. Antoniol, V. Rajlich, “Combining Probabilistic Ranking and Latenet Semantic Indexing for Feature Identification”, In 14th IEEE Int. Conf. on Program Comprehension, pp. 137-148, Athens, 2006. E. Souza, C. Gusmão, “RBTProcess - Modelo de Processo de Teste de Software baseado em Riscos”, in 13º Workshop de Teses e Dissertações em Engenharia de Software, 2008. E. Souza, C. Gusmão, K. Alves, J. Venâncio, R. Melo, “Measurement and Control for Risk-based Test Cases and Activities” in 10th IEEE Latin American Test Workshop, LATW, Búzios, Rio de Janeiro, 2009. E. Souza, C. Gusmão, J. Venâncio, “Risk-Based Testing: A Case Study”, in 7th International Conference on Information Technology : New Generations (ITNG), Las Vegas, 2010. G. Shi, Y. Kong, “Advances in Theories and Applications of Text Mining”, in ICISE, 2009. J. Venancio, C. Gusmão, E. Mendes, E. Souza, “RBTTool: Uma Ferramenta de Apoio à Abordagem de Teste de Software baseado em Riscos”, in XXIII Simpósio Brasileiro de Engenharia de Software, Fortaleza, 2009. K. Verma, A. Kass. Requirements Analysis Tool : A Tool for Automatically Analyzing Software Requirements Documents, 2008. S. Weiss, N. Indurkaya, T. Znag, F. Damerau. Text Mining - Predictive Methods for Analyzing Unstructured Information, 2005. R. Witte, Q. Li, Y. Zhang, J. Rilling, “Text Mining and Software Engineering: An Integrated Source Code and Document Analysis Approach”, in IET Software Journal, v. 2, n. 1, pp.3-16, 2008. 85 Non-Termination Attacks Based on Integer Overflows Raphael Ernani Rodrigues Department of Computer Science – The Federal University of Minas Gerais (UFMG) – Brazil [email protected] Advisor: Fernando Magno Quinto Pereira ([email protected]) Level: Master Beginning Year: 2012 Conclusion Date: March/2014 Project Approval Date: December/2012 Abstract. There are several ways to attack a computer and make it unavailable to its genuine users. A way of reaching such goal is by consuming all the target system’s resources with false requests. This kind of attack is called Denial-of-Service (DoS) attack and is usually done with millions of simultaneous requests to the target machine, consuming all of its network bandwidth. However, it is also possible to achieve the same result through a few requests that make the served program to loop forever. This is called NonTermination Attack and allows the adversary to take down the server with a small number of requests, avoiding the defenses against DoS attacks. In this work we present a diagnosis and a solution for this type of attack. Firstly, we describe a tainted-flow analysis that detects non-termination vulnerabilities. Secondly, we provide a compiler transformation that inserts arithmetic guards on loop conditions that may not terminate due to integer overflows. Finally, we will use abstract interpretation, a static code analysis technique invented on the seventies, to create assertions that avoid program non-termination. At this moment, we have finished the first two steps of our solution. We have implemented our framework in the LLVM compiler, and have tested it on a benchmark suite containing over 2.5 million lines of C code. Our instrumentation prevents non-termination attacks based on integer overflows, adding 5% extra code and causing less than 1% of slowdown on the secured programs, on average. The next step of this project is the research of an advanced static analysis to infer which ranges of the input values may cause non-termination in the target programs. With these values, we will be able to create automatic assertions that ensure termination. This part of the work is currently being pursued in France, under the guidance of Christophe Alias and Laure Gonnord. Keywords: Integer Overflow, Denial-of-service, Compiler, Code Analysis CBSoft Event: SBLP 86 1 Introduction Servers connected to the web are frequently attacked with the objective of making some services unavailable to their users. The trivial way of doing that is by physically disconnecting the server from the network. However, in most cases the attackers do not have physical access to the target machines, so they use other strategies, like the Denial-of-Service (DoS) attacks, to produce the same practical result. The DoS attack consists on overloading a server with an amount of false requests that is large enough to compromise the capacity of dealing with the genuine demand. Usually, the DoS attacker does millions of simultaneous requests to the target server causing an unexpected peak of processing, memory consumption or network bandwidth usage. This situation leads the server to a state in which it refuses connections from new users, satisfying the goal of the attack. However, there is a class of Denial-of-Service attacks that is not covered by the current defense strategies: the non-termination attacks. An adversary can perform an attack like that by providing to the target program some carefully crafted inputs to force eternal iterations over a vulnerable loop. This kind of attack can be very effective, because with few requests it is possible to compromise the target server. Once the number of incursions is small, the traditional methods of detection and prevention of DoS attacks [7] cannot be used to recognize non-termination attacks. This work brings two contributions related to non-termination attacks. Firstly, we propose a tainted flow analysis to detect which loops of a program are vulnerable to non-termination attacks. Secondly, we propose a way to secure the programs against this kind of attack, by automatically adding checks to the source code. Currently, we have implemented our contributions in LLVM, an industrial quality compiler [6]. Our instrumentation – used to avoid non-termination attacks – has been proved to be very effective. The tests that we have inserted after each arithmetic operation that can lead to a non-termination cause a performance loss of 0.61% on average. 2 Non-Termination Attacks Definition of Data Inputs. The data inputs are the ways that an adversary can use to force the non-termination of a program. In this work, we consider as data inputs the following values: – the arguments of the method main, i.e. the variables argc and argv; – the result of external functions; – pointers passed as arguments to external functions. External functions are the union of the following three sets: – functions that are not declared in any of the files of the compiled program; – functions without body; 87 Fig. 1. (a) A function in C, that calculates the factorial of an integer number. (b) The CFG of the function fact. (c) The dependence graph of the variables of the function. – functions that can be called through a function pointer. Definition of Loop. We consider the definition of natural loop given by Appel e Palsberg [1, p.376]. The same ideas can be applied to other kinds of loops, but we chose to focus on natural loops for simplicity reasons. Definition of Data Dependencies. If a program P has an instruction that uses the variable u and defines a variable v, then v depends on u. Data dependencies may be cyclical. Non-Termination Conditions. Let the stop condition of a loop be a boolean expression E = f (e1 , e2 , . . . , en ), where each ej , 1 ≤ j ≤ n is a value that contributes to the computation of E, and P be a program that has a loop L limited by a stop condition E = f (e1 , e2 , . . . , en ). We say that P is vulnerable to a non-termination attack when both of the two following conditions about it are true: 1. there is a subset E 0 ⊆ {e1 , e2 , . . . , en } of values that depend on a set I = {i1 , i2 , . . . , im } of data read from the public input of the program. 2. there is an assignment of values i1 7→ v1 , i2 7→ v2 , . . . , im 7→ vm that, influencing E 0 , leads L to never end. Data Dependence Graph. We use the data dependence graph [4] to determine vulnerable loops. This graph is built in the following way: for each variable v of the program, we insert a node nv , and for each instruction i, we create a node ni . For each instruction i : v = f (. . . , u, . . .) that defines a variable v and uses a variable u we create two edges:nu → ni and ni → nv . Example. Figure 1(a) illustrates the non-termination attack. This program calculates the factorial of an integer number in the language C. Considering that the type int represents integer numbers as 32-bit numbers in two’s complement, the largest integer that can be represented is MAX INT = 231 −1 = 2, 147, 483, 647. If the parameter n is equal to MAX INT , then the condition of line 4 will always be true, and the loop will never end. The non-termination occurs because when i finally receives the value MAX INT , the sum i + 1 returns the lowest integer possible, which is −231 . 88 3 3.1 Detection and Prevention of Non-Termination Detection of Vulnerable Loops We say that a loop is vulnerable when it is controlled by a predicate p that depends on an input value i and on a value v produced by a cyclical arithmetic operation that may overflow. Thus, if we can find in the dependence graph a path from nv to np and a path from ni to np , then the loop controlled by p is vulnerable. According to the definition of loops of Appel and Palsberg, a cyclical operation is any instruction that belongs to the body of the loop. For instance, in the CFG from figure 1(b), the instructions i2 = i1 + 1 e r2 = r1 × i1 are cyclical. The dependence graph that we have extracted from the CFG in figure 1(b) is shown in figure 1(c). The loop from that example fits in our definition of vulnerability, because its stop condition p is reachable from the input n and it depends on a cyclical instruction that may result in an overflow: i2 = i1 + 1. 3.2 Loop Sanitizing Vulnerable loops can be sanitized through the insertion of tests that detect and handle the occurrences of integer overflows. The behavior of the overflow handler is customizable by the user of our solution. Again, the dependence graph helps us to find which operations have to be instrumented to sanitize a loop controlled by a predicate p. In this case, we use the following criterion to determine if an operation i : v = f (v1 , . . . , vn ) needs to be instrumented: – There exists a path from the node ni to the node np . – The node ni belongs to the cycle controlled by np . – The operation i may result in an integer overflow. As an example, the increment operation ++ in the dependence graph seen in figure 1(c) needs do be instrumented. Firstly, because this operation belongs to a cycle. Secondly, because there is a path from the node n++ to the node np . 3.3 Loop Assertions As an alternative to loop sanitizing, we also propose the creation of static assertions to ensure the termination of the program. The advantage of the static approach over the insertion of dynamic checks is that the secured program do not need to be executed until the occurrence of an overflow to stop. Instead, the execution can be aborted once the input values fulfill a non-termination criteria. Other advantage of this approach is that the instrumentation is inserted outside the loops. With this, we expect an overhead lower than the overhead caused by the dynamic checks. On the other hand, the analysis that makes possible to create such assertions is expensive. This part of the work is currently being developed in France. 89 Benchmark 433.milc 444.namd 447.dealII 450.soplex 470.lbm 400.perlbench 401.bzip2 403.gcc 429.mcf 445.gobmk 456.hmmer 458.sjeng 462.libquantum 464.h264ref 471.omnetpp 473.astar 483.xalancbmk Total Loops Vulnerable Arits. Instr. Growth Slowdown 329 484 4759 542 18 1160 211 3824 39 1082 681 235 79 1614 363 88 2212 138 408 2657 453 0 315 95 1297 2 499 255 109 41 161 201 50 1061 1101 3136 1491 0 1779 1130 7983 1684 14338 158 11856 3210 2138 593 13398 2029 639 12528 150 932 3762 771 0 655 240 2072 4 932 419 167 68 411 249 99 1562 9,49% 15,75% 6,40% 17,83% 0,00% 2,92% 17,20% 3,26% 2,00% 9,73% 10,08% 9,97% 14,49% 3,81% 3,91% 16,46% 2,52% 0,03% -0,13% 1,84% 0,00% 0,34% -2,11% 0,95% 0,09% 0,64% 0,42% 0,19% 4,16% 1,55% - 17720 7742 92610 12493 5,02% 0,61% Fig. 2. Data collected from our Loop Sanitizer. Loops: number of loops in the program. Vulnerable: number of loops that fulfill our requirements of vulnerability. Arits.: number of instructions that may cause integer overflows. Instr.: amount of checks inserted to sanitize the program. Growth: ratio of the instrumented program size to the original program size. Slowdown: slowdown produced by our instrumentation. 4 Experimental Results We have implemented the techniques described in this paper as a plugin for the LLVM compiler, version 3.3. Our implementation has been tested on an Intel Core i7-3770, with 16 Gigabytes of RAM, and 3.40 GHz clock. We have successfully executed our analysis over the whole LLVM test framework, a set of programs with more than 4.3 million of lines of code written in C. In the rest of this section we will show only results obtained with the programs available in SPEC CPU 2006. The figure 2 presents the data collected by our instrumentation. It shows that 43,7% of the loops are vulnerable. However, we only had to insert overflow checks in 13,5% of the arithmetic instructions that may overflow. Thus, the instrumented programs are 5,02% larger than the original and the performance loss is 0,61%, on average. Similar results can be achieved in other compilers, such as GCC, because we do not rely in any resource that only applies to LLVM. 5 Related Works This work is related with others that also try to detect, statically, the nontermination of programs. Most of these works use symbolic analysis to create expressions that lead a loop to non-termination. Examples of this kind of research include the works of Burnim et al. [3], Brockschmidt et al [2], Veroyen 90 et al. [9], Gupta et al. [5] and Son et al. [8]. In contrast to those works, our current implementation does not use computationally expensive algorithms and we focus on integer overflows. Thus, we can handle very large programs, while other solutions only have been applied to small problems. We are now working with abstract interpretation to develop an analysis that statically detects nontermination conditions, improving the protection we provide without inserting checks inside loops. 6 Conclusion In this paper we have described a method of DoS attack that tries to lead the target program to the non-termination. Contrary to the related literature, we focus on non-termination caused by overflows of integer arithmetics. This phenomenon characterizes languages like Java, C and C++. We have defined some properties needed to the effective occurrence of a non-termination attack, which are: loop condition controlled by an adversary and cyclical operations resulting in integer overflows. Then, we have shown how to eliminate the last of these conditions through checks inserted by the compiler. Finally, we have shown experimentally that our checks, even if inserted conservatively, do not compromise the run-time of the instrumented programs. We have demonstrated with this that the prevention to non-termination attacks based in integer overflows is cheap and effective. The next step of this work – the static analysis to create assertions – is already being researched. Software: our techniques were all implemented in LLVM, and are publicly available through the URL http://code.google.com/p/range-analysis/. References 1. Andrew W. Appel and Jens Palsberg. Modern Compiler Implementation in Java. Cambridge University Press, 2nd edition, 2002. 2. Marc Brockschmidt, Thomas Ströder, Carsten Otto, and Jürgen Giesl. Automated detection of non-termination and nullpointerexceptions for java bytecode. In FoVeOOS, pages 123–141. Springer-Verlag, 2012. 3. Jacob Burnim, Nicholas Jalbert, Christos Stergiou, and Koushik Sen. Looper: Lightweight detection of infinite loops at runtime. In ASE, pages 161–169. IEEE, 2009. 4. J. Ferrante, K. Ottenstein, and J. Warren. The program dependence graph and its use in optimization. TOPLAS, 9(3):319–349, 1987. 5. Ashutosh Gupta, Thomas A. Henzinger, Rupak Majumdar, Andrey Rybalchenko, and Ru-Gang Xu. Proving non-termination. SIGPLAN Not., 43(1):147–158, 2008. 6. Chris Lattner and Vikram S. Adve. LLVM: A compilation framework for lifelong program analysis & transformation. In CGO, pages 75–88. IEEE, 2004. 7. David Moore, Colleen Shannon, Douglas J. Brown, Geoffrey M. Voelker, and Stefan Savage. Inferring internet denial-of-service activity. ACM Trans. Comput. Syst., 24(2):115–139, 2006. 8. Sooel Son and Vitaly Shmatikov. SAFERPHP: finding semantic vulnerabilities in php applications. In PLAS, pages 8:1–8:13. ACM, 2011. 9. Helga Velroyen and Philipp Rümmer. Non-termination checking for imperative programs. In TAP, pages 154–170. Springer-Verlag, 2008. 91 OdysseyPrLE-CBArch: A Process Reuse Approach Combining the Software Process Line and Process Component Based Architecture Approaches Eldanae Nogueira Teixeira, Cláudia Werner Federal University of Rio de Janeiro COPPE - System Engineering and Computer Science P.O. Box 68511 - Rio de Janeiro, RJ 21945-970 Brazil {danny, werner}@cos.ufrj.br Level: Ph. D. Admission year: 2011 PhD Thesis Conclusion estimate: 2015 Approval of candidate’s PhD thesis proposal: to be defined CBSOFT related events: SBCARS and SBES Abstract. Given the diversity of organizations’ and projects’ aspects, the process definition task is not simple. The use of combined process reuse techniques, such as Software Process Lines and Process Component Based Development, aims at contributing to improvements in productivity and quality, associated with effort and costs reductions involved in this task. The goal of this PhD thesis is to define, implement, and evaluate a systematic process reuse approach within a Software Process Line Engineering, which treats variability property inherent to process families and structures the domain knowledge by process component based architecture. Keywords: Software Process, Process Reuse, Process Component, Software Process Line, Process Variability 92 1. Problem Characterization There is a strong relationship between software quality and the software process defined to support its development [Osterweil 1987, Fuggetta 2000]. Therefore, many organizations have invested in specifying and improving their software processes. But the definition of processes is a non-trivial task. There are many factors to consider, such as: organization's or projects' needs and characteristics, techniques and methods to use, adherence to standards and reference models, business constraints (schedule, costs, etc), among others [Barreto et al. 2008]. The complexity of this task leads to the need to organize the knowledge acquired in previous projects and to characterize, use, and manage both the similarities and differences among process families and family members [Sutton and Osterweil 1996]. A process reuse approach can be used as a support to the process definition activity. Applying the valid analogies between software product and software process [Osterweil 1987], the knowledge of software product reuse topics such as architectures populated with reusable components; repository (a.k.a. library) management; configuration management of reusable assets can be applied to software process reuse [Kellner 1996]. So, based on some software reuse approaches [Blois 2006] which analyze the opportunity to combine the Software Product Line (SPL) approach [Northrop 2002] and the concepts and techniques of Component Based Development (CBD) [Sametinger 1997], the same opportunity can be proposed to the process reuse area. SPL concepts have been mapped to the Software Process Line (SPrL) techniques, which apply the idea of SPL for processes [Rombach 2006]. CBD aspects have been applied by approaches that conduct the definition of software processes using components [Gary and Lindquist 1999, Barreto et al 2008] and, in some cases, organizing them into architectures [Chrissis et al. 2006, Humphrey 1989]. So, a challenge that could be identified is to promote software process reuse by a systematic reuse approach that treats the variability property inherent of process families and structures the domain knowledge by process component based architecture. Current methods for SPrL development lack an approach with a systematic process with different phases, contemplating multiple abstraction levels and types of artifacts, as well as a proper notation for addressing the process domain variability and mechanisms to guarantee consistency among the corresponding artifacts. The goal of this PhD thesis is to define, implement, and evaluate an effective systematic process reuse approach. This involves the definition of a Software Process Line Engineering (SPrLE) composed by five main elements: i) a method, which is a Process Domain Engineering process focused on Component Based Process Definition (CBPD); ii) a more complete representation to variability modeling, addressing different abstraction levels and types of artifacts; iii) a mapping mechanism as a guide to assist the mapping of properties and variability throughout different domain artifacts; iv) criteria to support the creation of a process architecture; and v) a supporting environment. This research extends the candidate’s master dissertation entitled “OdysseyProcess-FEX: An Approach for Variability Modeling of Software Process Line” [Teixeira 2011]. 2. Background A software process can be defined as the coherent set of policies, organizational structures, technologies, procedures, and artifacts that are needed to conceive, develop, deploy, and maintain a software product [Fuggetta 2000]. Bearing in mind that 93 organizations are different and that, two projects within the same organization can also be different [Cugola and Ghezzi 1998], there is no software process that can be generally applied to all projects. This implies a process variability that can be specified as defining, establishing the scope, and executing changes in a systematic and consistent manner, in order to adapt the process models to the unique characteristics of the project in a given context [Martínez-Ruiz et al. 2012]. To achieve effective process reuse, it is necessary to develop efficient methods to capture the common and variable elements of specific processes and create process definitions that can be applied in a variety of situations, i.e., that are reusable [Hollenbach and Frakes 1996]. Just as there are valid analogies between software product and software process [Osterweil 1987], there are valid analogies between software reuse and software processes reuse. Thus, SPrL was proposed as a systematic technique for processes reuse, which applies the principles of SPL in processes. Another approach consists in the definition of software process based on process components, which can be considered an encapsulation of process information and behaviours at a given level of granularity [Gary and Lindquist 1999]. These process components are organized by a process architecture, a structure that establishes the process elements involved, the interfaces, ordering, interdependencies and other relationships among them [Chrissis et al. 2006]. A SPrL is defined as a set of processes in a particular domain or for a particular purpose, having common characteristics and built based upon common, reusable process assets (such as Process Line Architectures, requirements) [Washizaki 2006]. According to [Rombach 2006], the main characteristics of SPrLE include: (i) two separate development processes in which one distinguishes between the Domain Engineering process, by which processes for reuse are being created, and the Application Engineering process, by which project-specific processes are being developed; (ii) a process repository where reusable processes at all abstraction levels are made available; (iii) a systematic reuse process to select process components for predefined variabilities; (iv) a systematic process management process where, for each exception, it will be decided whether this exception will be factored into the generic process or not. 3. Contribution and Methodology The goal of this PhD thesis is to define, implement, and evaluate a systematic process reuse approach, combining SPrL approach with CBPD. This involves the definition of a SPrLE, a systematic method to develop a SPrL with a Process Domain Component Architecture, considering the domain variability, as the final result. This is composed by multiple phases with different abstraction levels and types of artifacts, as well as notations for addressing the process domain variability and mechanisms to guarantee consistency in the traceability among artifacts. The methodology to develop the approach proposed consists of: (1) conducting a literature review in the main areas involved in this thesis; (2) specifying the SPrLE method, describing the processes workflows for a Software Processes Domain Engineering (SPDE) and a Software Processes Application Engineering (SPAE) focused on CBPD; (3) the definition of a more complete representation to variability modeling, addressing notations for the different abstraction levels and types of artifacts; (4) the definition of procedures to support the mapping of variability throughout different domain artifacts; (5) the definition of criteria to support the creation of a process component architecture; (6) support for mapping technology-independent 94 components; and (7) developing a supporting environment as a prototype of a process reuse infrastructure. Also, an evaluation of the approach should be defined and conducted. In this context, some elements are identified as critical to the SPrL structure development (Figure 1). Modeling notations for representation of the multiple software process domain artifacts Definition of software process domain artifacts structured by abstraction levels. SPrL Representation of process components in an executable Process Modeling Language Mapping procedures to establish the traceability between the multiple software process domain artifacts Software process components specification and their organization in reuse reference architecture Figure 1 – Critical elements of a SPrL structure development A literature review was planned to be conducted in the main areas involved in the thesis. The software process area and its engineering life cycle set the theoretical basis of our approach, including a brief review of the modeling topic and how the concept of variability is described in this research field. The SPrL area has been investigated according to some criteria: (1) definition of systematic reuse through processes for and with reuse, (2) variability modeling, and (3) the existence of an environment to support process reuse. The CBPD area has also been investigated in order to characterize the existing approaches and determine the process component concept and the definition of process architecture for the process domain. This analysis helps ensuring that previous results are considered in our approach development. Some works have been developed on the topic of SPrLs [Washizaki 2006, Armbrust et al. 2009, Barreto et al. 2008, Aleixo et al. 2010, Alegría et al. 2012]. Despite the efforts in the area, there is no united approach or consensus regarding how to perform process tailoring in a controlled and consistent manner [Martínez-Ruiz et al. 2012]. None of the analyzed works provides an integrated strategy as a framework for SPrLs such as the systematic approach used by SPL [Northrop 2002]. Some of the approaches represent a first step, describing the ideas involved in the area but not providing a concrete proposal for dealing with SPrLs. Others deal with only some parts of the whole process involved in the construction and use of a SPrL. Also, there are few works that try to combine the opportunities of the two areas, i.e., SPrL and CBPD. In this aspect, this work is a starting point to propose a systematic process through the specification of a SPrLE method focused on CBPD. The SPrLE method describes the sequence of activities in order to create, use and manage a SPrL. Its two phases, SPDE and SPAE, are divided in three main activities: (1) Analysis; (2) Design; and (3) Implementation. For each activity, a detailed specification of the steps that should be conducted to achieve the required outcome should be described. Also, the representation is specified by a software process modeling with variability support. A list of desirable concepts for a software process variability modeling can be derived from a set of desirable requirements for a notation to express variability in a software domain artifacts in SPL approaches, such as: (1) The representation should be graphical; (2) The representation should make the fixed process elements, the configurable process elements and their alternatives explicit; (3) The representation should make the degree of optionality of each process element explicit; (4) The representation should make the relationships explicit; and (5) The representation should make relations of dependency and mutual exclusivity between the elements explicit to guarantee the consistency of the process instances to be generated. A set of works that are related to the theme of SPrLs were analysed in Teixeira (2011). Summarizing the analyses, we observed that none of the proposed representations can fully and explicitly meet the requirements of a notation geared for variability representation. Complementing this, one of the conclusions of the SLR that identified the requirements 95 for process tailoring notation [Martínez-Ruiz et al. 2012] was that only few studies propose a special notation to represent variability in processes, and the development of a variability notation was indicated as a real need. Also, the idea of multiple semantic abstraction levels to specify the SPrL is not held as complementary representations with traceability rules. This approach treats the SPrL modeling using different abstraction levels to guide its development in a complementary strategy. The first abstraction level represents the SPrL conceptual view, which defines the reusable software process basic elements (work units, roles and work products) and analyzes their variability property in the domain. The second level is the SPrL representation through a structural and a behavioral view. The structural view details how the software process work units can be conducted by defining the steps involved and its relation to other process elements (work products, roles, tools). In addition, the possible software process behaviors are specified through execution flows and sequences in the behavioral view. The final SPrL representation consists of a Software Process Component Architecture, a structure that defines the process components relations and can be considered as a skeleton. So, the SPrL approach proposes software process reuse by building blocks with its concepts encapsulated and its communication established by interfaces. The definition of the concept of software process component should be derived as a result of this approach. Also, the interface concept and the different relationships that are possible to establish among them to derive a composed process has to be defined through the architecture specification. An implementational view is responsible for representing the components through an execution specification. In each level, the variability aspect needs to be accordingly worked and represented. To maintain the consistency across these levels, a mapping procedure should be defined, establishing the traceability among the different domain artifacts. The supporting environment should be realized as a reuse infrastructure that supports the proposed SPrLE approach. This will be achieved by adapting the Odyssey environment [Odyssey 2013], which has been extended to support part of the analysis activity of SPDE in [Teixeira 2011]. Odyssey is a reuse infrastructure based on software domain models and supports all phases of software reuse. It has been developed by the Software Reuse Group at COPPE/UFRJ. The environment has a hierarchical internal structure represented through a semantic tree of objects, which is organized in decreasing levels. The adaptation here indicated means to extend the environment to support all phases of SPDE and SPAE. This means to implement the different abstraction levels and its correspondent domain model. Also, the mapping procedures should be implemented to assist the process domain engineer to develop a SPrL gradually and consistently. The evaluation of the approach will be conducted by different studies. First, it is planned to structure an example using the process to construct the SPrL with the proposed multiple abstraction levels and the corresponding notations. To evaluate the reusability quality attribute of the derived SPrL artifacts, checklists can be defined. The conceptual view can be evaluated by a checklist derived from the FMCheck [de Mello et al. 2012], a checklist-based inspection technique for supporting the semantic verification of feature models. For the other levels, similar checklists will be developed trying to cover the detection of defects by inspections. The Software Process Component Architecture could be evaluated by a method derived based on an inspection process based on the ArchMine approach [Vasconcelos and Werner, 2007]. The criteria to be derived for the evaluation technique should support the detection of discrepancies 96 that may compromise the reusability of process components that compose the architecture analyzed. Also, reuse aspects like variability should be evaluated to analyze the consistency of these properties along the SPrL development. This evaluation proposal helps to verify the possibility to derive consistent software processes using the SPrL. Some studies could be conducted to evaluate the feasibility and effectiveness of these techniques in comparison with ad-hoc inspections within distinct domains which can be empirically observed. Other methods of evaluation should be designed to verify the applicability of the approach. 4. Current State and Preliminary Results A preliminary literature review was conducted proving the theoretical basis for the SPrL and CBPD areas. In the context of this PhD thesis, a preliminary SPrLE method is being proposed, called OdysseyPrLE-CBArch approach (Odyssey Process Line Engineering – Process Component Based Architecture). The main phases of OdysseyPDE-CBArch process are depicted in Figure 2, together with the respective artifacts. Each type of artifact represents domain elements according to a point of view and an abstraction level. Starting from the conceptual view artifacts are recursively generated one from another as a result of SPDE analysis, design or implementation activities. These generation activities are supported by mapping procedures, in order to maintain the consistency by the multiple artifacts, propagating the variability to all domain artifacts. Process Domain Analysis Phase To specify process features in conceptual view and process elements and workflows in structural and behavioral view Structural Model SPEM notation adapted Behavioral Model UML Activity Diagram adapted Feature Model OdysseyProcess-FEX notation Process Domain Design Phase To specify process components and the SPrL architecture Process Components Process Domain Architecture Figure 2 - Phases and Models of OdysseyPDE-CBArch The domain model should gather all the Process Domain Knowledge, with an explicit representation of its commonality, variability and optionality. One way of representing a SPrL on an easy-to-understand level of abstraction is through the concept of features, intensively used in SPL. This is represented using the OdysseyProcess-FEX notation [Teixeira 2011]. The structural view is represented by an adaption of the SPEM notation [OMG 2008] in order to contemplate an explicit variability modeling. SPEM 2.0 is the OMG standard for software process specification. It is the most widespread and popular language for representing software processes [Ruiz-Rube et al. 2012]. However, some extensions are being proposed for improving certain deficiencies in the SPEM meta-model, including the support to the development of software process lines [Ruiz-Rube et al. 2012]. So, based on the knowledge developed in these extensions and trying to improve them, we propose some extensions to this notation to represent the structure of the multiple processes that compose the SPrL and explicitly represent the variation points and their variants and the optionality present in some of the elements. The behavioral view is represented by an adaptation of the UML Activity Diagram [OMG 2005], describing the different possibilities of workflows, considering the variability property of the elements. The activity diagram is the most used diagram in all approaches that represent the process workflow. Our approach is based on Puhlmann et al. (2005) proposal. It introduces variability mechanisms for Activity Diagrams in order 97 to support variability in process models. The component view will be represented by a notation which is being constructed based on the process component representations available in the literature [OMG 2008, Barreto et al. 2008, Gary and Lindquist 1999, Bhuta et al. 2005]. To capture variability in these artifacts, stereotypes are being proposed, which are used in combination with relationships to preserve the domain semantics. 5. Expected Results Given the complexity involving in defining a specific process for a project, a systematic process reuse can assist this activity by introducing the benefits of a planned reuse process based on the SPrL and CBPD concepts. The objectives of using SPrLE are – as in the case of all reusable approaches - increased predictability, reduced cost and time, and reduced risk [Rombach 2006]. The combination of the two areas could increase the benefits of a process reuse approach. References Armbrust, O., Katahira, M., Miyamoto, Y., Münch, J., Nakao, H. and Ocampo, A. (2009) "Scoping Software Process Lines", In: Software Process: Improvement and Practice, 14, 3, 181-197. Alegría, J.A.H. and Bastarrica, M.C. (2012) “Building software process lines with CASPER”, In: International Conference on Software and System Process. Zurich, Suíça, IEEE. Aleixo, F.A., Freire, M.A., Santos, W.C.d. and Kulesza, U. (2010) “A Model-driven Approach to Managing and Customizing Software Process Variabilities”, In: 12th International Conference on Enterprise Information Systems. Funchal, Madeira, Portugal, SciTePress. Barreto, A., Murta, L. and Rocha, A.R. (2008) “Software Process Definition: a Reusebased Approach”, In: XXXIV Conferencia Latinoamericana de Informática (CLEI'08), Santa Fe, Argentina, pp. 409-419. Bhuta, J.; Boehm, B.; Meyers, S., 2005, “Process Elements: Components of Software Process Architectures.” In: Proceedings of the Software Process Workshop, pp. 332346, Beijing, China. Blois, A., de Oliveira, R., Maia, N., Werner and C., Becker, K. (2006) “Variability Modeling in a Component-based Domain Engineering Process”, In: 9th International Conference on Software Reuse, Turin, Italy, June, Lecture Notes in Computer Science, Springer, Heidelberg, Germany, ISSN 0302-9743, pp. 395-398. Chrissis, M.B., Konrad, M. and Shrum, S. (2006) “CMMI: Guidelines for Process Integration and Product Improvement”, In: 2nd ed., Nova York, Estados Unidos: Addison-Wesley Cugola, G. and Ghezzi, C. (1998) “Software processes: The retrospective and the path to the future”, In: Journal of Software Process Improvement and Practice (SPIP), v.4, pp. 101-123. de Mello, R. M., Teixeira, E. N., Schots, M., Werner, C. M., & Travassos, G. H. (2012) “Checklist-based Inspection Technique for Feature Models Review”, In: 6th Brazilian Symposium on Software Components Architectures and Reuse (SBCARS), 2012 (pp. 140-149), September. 98 Fuggetta, A. (2000) “Software process: the roadmap”, In: Proceedings of the Conference on The Future of Software Engineering, Limerick, Ireland, pp. 25-34. Gary, K.A. and Lindquist, T.E., (1999) “Cooperating Process Components”, In: COMPSAC99, pp.218-223. Phoenix, United States. Hollenbach, C. and Frakes, W. (1996) “Software Process Reuse in an Industrial Setting”, In: 4th International Conference on Software Reuse, Orlando, United States, pp.22-30. Humphrey, W. S., (1989) “Managing the Software Process”, In: Boston, MA, USA, Addison-Wesley. Martínez-Ruiz, T., Münch, J., García, F. and Piattini, M. (2012) “Requirements and constructors for tailoring software processes: a systematic literature review”, In: Software Quality Journal, vol. 20, no 1, p. 229–260. Odyssey (2013) “Odyssey Project”, In: http://reuse.cos.ufrj.br/odyssey OMG (2011) “Object Management Group - Unified Modeling Language (UML) Superstructure Specification, version 2.4.1, 2011”. In: http://www.omg.org/spec/UML/2.4.1/Superstructure/PDF OMG (2008) “Software Process Engineering Metamodel”, http://www.omg.org/technology/documents/formal/spem.htm. In: Osterweil, L. (1987) “Software processes are software too”, In: International Conference on Software Engineering (ICSE), Monterey, CA, USA, pp. 2-13. Puhlmann, F, Schnieders, A., Weiland, J. and Weske, M. (2005) “Variability mechanisms for process models”, PESOA-Report TR, vol. 17, p. 10–61, 2005. Rombach, D. (2006) “Integrated Software Process and Product Lines”, In: Unifying the Software Process Spectrum, Berlin/Heidelberg: Springer-Verlag, pp. 83-90. Ruiz-Rube, I., Dodero, J.M., Palomo-Duarte, M., Ruiz, M. and Gawn, D. (2011) “Uses and Applications of SPEM Process Models. A Systematic Mapping Study”, In: Journal of Software Maintenance and Evolution: Research and Practice, pp. 1-32. Sutton, S. and Osterweil, L. (1996) “Product families and process families”, In: Proceedings of the 10th International Software Process Workshop (ISPW), pp. 109111, Dijon, France. Teixeira, E.N. (2011) “OdysseyProcess-FEX: An Approach for Variability Modeling of Software Process Line”. Dissertação de M.Sc., COPPE/UFRJ, Rio de Janeiro, RJ, Brasil (in Portuguese). Vasconcelos, A, and Werner, C. (2007) “Architecture Recovery and Evaluation Aiming at Program Understanding and Reuse”, In: International Conference on Quality of Software Architectures (QoSA 2007), Boston, MA, USA, July, Lecture Notes in Computer Science, Springer, Heidelberg, Alemanha, ISSN 0302-9743, pp. 72-89. Washizaki, H. (2006) “Building Software Process Line Architectures from Bottom Up”, In: Product-Focused Software Process Improvement (PROFES), Amsterdam, The Netherlands: LNCS, chapter 4034, pp. 415-42. 99 Otimizações de Código Sensı́veis ao Contexto de Chamada Matheus Silva Vilela ([email protected]) Mestrado em Ciência da Computação Departamento de Ciência da Computação – UFMG – Brasil Orientador: Fernando Magno Quintão Pereira ([email protected]) Data de ingresso: março/2012 Previsão de Conclusão: março/2014 Data de aprovação da proposta: fevereiro/2013 Palavras-chave: otimização, sensibilidade ao contexto, LLVM Evento relacionado: SBLP Abstract. Compilers are essential to optimize code, leaving to the programmer the task of designing algorithms, while abstracting the complexity of micro optimizations away. Today compilers can generate code almost as efficient as a seasoned assembly programmer. However, most of the optimizations that compilers perform are context independent. The context of a function call is the dynamic execution path from the beginning of the program execution to the point in time when the function is called. Performing context sensitive optimizations is difficult because there are simply too many contexts that the compiler must track. In this work, we propose to advance the state-of-the-art algorithms that perform context sensitive optimizations. Our goal is to perform specific context aware optimizations. If successful, we hope to design and implement a new kind of code optimizer, that clones functions, using the best clone in each calling context. Resumo. Compiladores são essenciais para otimizar código, deixando para o programador a tarefa de projetar algoritmos, abstraindo a complexidade das micro-otimizações. Os compiladores de hoje são capazes de gerar código quase tão eficiente quanto aquele feito por um programador de assembly experiente. Entretanto, a maioria das otimizações feitas por compiladores são independentes de contexto. O contexto da chamada de uma função é o caminho dinâmico de execução do inı́cio do programa até o ponto em que a função é chamada. Realizar otimizações sensı́veis ao contexto é difı́cil, já que existem muitos contextos que o compilador deve levar em consideração. Nesse trabalho , propomos um avanço no estado-da-arte dos algoritmos que realizam otimizações sensı́veis ao contexto. Nosso objetivo é realizar otimizações sensı́veis ao contexto especı́ficas. Se obtivermos sucesso, esperamos projetar e implementar um novo tipo de otimizador de código, responsável por clonar funções, usando o melhor clone em cada um dos contextos de chamada. 100 1. Introdução As diferenças nos contextos de chamada das funções proporcionam novas oportunidades de otimização de código. Intuitivamente, se um segmento de código pudesse ser otimizado de acordo com suas diferenças de comportamento em diferentes contextos de chamada, a performance do programa, como um todo, seria melhorada. Entretanto, otimizações clássicas de compiladores não consideram o contexto de chamada para aplicar suas transformações. A limitação dos compiladores, nesse caso, deve-se à sensibilidade ao contexto. A integração de procedimentos, ou inlining de funções, é uma forma que compiladores possuem de mitigar tal problema. Entretanto, a integração de procedimentos pode levar a um crescimento exponencial do programa transformado. Além disso, funções recursivas não podem ser integradas [Keith D. Cooper 2012, pg.458]. Nesse trabalho, nós propomos uma solução simples e completamente automática para realizar algumas otimizações sensı́veis ao contexto especı́ficas. O objetivo deste trabalho é implementar e testar uma técnica, baseada na clonagem de funções, que leva em consideração os contextos de chamada para aplicar otimizações especı́ficas. Em essência, procuraremos separar os pontos de chamada de funções em duas classes de equivalência: a primeira, denominada promissora, contém as chamadas que podem se beneficiar de uma otimização especı́fica, enquanto a segunda, denominada inócua, contém as chamadas para as quais tal otimização não se aplique. Para cada função otimizável, criaremos um clone, que terá seu código melhorado por uma otimização especı́fica. As chamadas promissoras serão substituı́das por chamadas da função modificada, enquanto as chamadas inócuas continuarão invocando a função original. Implementamos algumas das técnicas descritas neste trabalho no compilador LLVM [Lattner and Adve 2004]. Os resultados obtidos até agora mostram-se promissores. O alcance das otimizações propostas é impressionante, podendo ser aplicadas em até um terços das funções disponı́veis em SPEC CPU 2006. Os ganhos de desempenho, entretanto, foram pequenos: os programas melhorados ficaram, em média, menos que 2% mais rápidos. Consideramos aqui que ambos os programas, original e transformado, são compilados com LLVM -O2. Especulamos que os ganhos pequenos devem-se ao fato de termos realizado essas otimizações sobre SPEC CPU 2006, uma coleção de programas já muito otimizados. Para testar tal hipótese, aplicamos nossas técnicas sobre aplicações de código aberto, obtendo resultados notáveis. Por exemplo, quando aplicadas a alguns benchmarks da companhia Adobe, as otimizações propostas levaram a ganhos de desempenho de até 31.2%. 2. Otimizações Propostas Conforme discutimos na seção anterior, neste trabalho pretendemos experimentar algumas otimizações baseadas na clonagem de funções. Nesta seção, descreveremos cada uma das otimizações de código já implementadas. Eliminação de Valores de Retorno não Usados. Em um programa, podem existir contextos onde o valor retornado por uma função não é utilizado. Na linguagem C, isso pode acontecer quando uma função retorna mais de um resultado para o programador, por meio de ponteiros passados como parâmetro, e somente um desses valores é interessante. Além disso, o programador pode estar interessado somente no efeito colateral gerado pela 101 função, não se importando com o valor de retorno. Nesses casos, seria interessante que nenhuma das instruções usadas para calcular tal valor fossem executadas. Nessa otimização, propomos a criação de um clone otimizado para as funções que sejam chamadas em contextos onde seu valor de retorno não seja armazenado. Nosso clone possui seu valor de retorno do tipo void, e não possui qualquer computação usada para determinar o antigo valor de retorno. O reconhecimento de contextos promissores nesse caso é simples: uma chamada r = f (. . .) pode ser substituı́da se o nome que ela define como retorno – r – é código morto. A detecção de código morto dá-se segundo uma análise clássica de código que omitimos por brevidade [Appel and Palsberg 2002, p.417]. Distinção de Apontadores. Na linguagem C, é comum o uso de apontadores como parâmetros de funções. Entretanto, como apontadores podem se sobrepor, eles comprometem o alcance das otimizações que um compilador pode aplicar sobre uma função. O uso do modificador restrict pode, nesses casos, trazer benefı́cios para a otimização do código. Esse modificador é um recurso que o desenvolvedor possui para informar ao compilador que um ponteiro não possui sinônimos no escopo da função em que é parâmetro formal. Dessa forma, o compilador fica livre para otimizar mais agressivamente o código. Embora essa otimização seja muito localizada, seus resultados são formidáveis. Experimentos realizados com funções simples que recebem dois ou mais ponteiros como parâmetro revelam que o uso do modificador restrict pode aumentar a eficiência de um código em até três vezes. Nessa otimização, propomos a criação de um clone de funções que recebem dois ou mais ponteiros como parâmetros, especializando-o de forma a adicionar o modificador restrict aos parâmetros. A fim de reconhecer contextos promissores para distinção de apontadores, deve-se determinar se os ponteiros usados como parâmetros reais são sinônimos ou não. Com esse intuito, implementamos e utilizamos a análise de apontadores de Andersen [Andersen 1994], aplicando a otimização somente quando nenhum dos apontadores se sobrepõem. Nı́vel de Sensibilidade a Contexto. As otimizações propostas nesse texto são disparadas por uma análise sensı́vel ao contexto do tipo 0-CFA [Shivers 1988]. Em outras palavras, nosso contexto é formado por somente um nı́vel de chamada de função. Somos capazes de distinguir uma chamada de função de outra, mas não somos capazes de distinguir invocações em sequências de duas ou mais chamadas aninhadas de função. Tal decisão acarreta em um custo mais baixo para aplicar as otimizações. Embora não tenhamos implementado a distinção de nı́veis mais profundos de contextos de invocação, especulamos, partindo dos resultados obtidos por Lhotak et al. [Lhoták and Hendren 2006], que nı́veis extra aumentariam muito pouco o alcance de nossas otimizações. 3. Resultados Experimentais Esta seção descreve uma série de experimentos que realizamos para validar tanto a eliminação de valores de retorno não usados quanto a distinção de apontadores. As otimizações foram testada em uma máquina com 12 núcleos de processamento Intel Xeon CPU E5-2665, com clock de 2.40GHz, 132 GB de RAM, executando o sistema operacional Ubuntu 12.04. Nossas otimizações foram implementadas sobre LLVM 3.3. Os testes que mostramos nesta seção foram executados sobre SPEC CPU 2006. 102 Clonagem de funções cujo valor de retorno não é utilizado depois da chamada Identificação Clonagem Substituição Programa Original LLVM -O2 exceto inline Eliminação de clones órfãos Clonagem de funções cujos parâmetros não podem apontar para a mesma memória. Identificação Clonagem Substituição Figura 1. Sequência de transformações que usamos para aplicar a clonagem de funções. Implementação das Otimizações A figura 1 descreve a sequência de transformações pela qual passa um programa que otimizamos. Cada uma dessas otimizações contém três etapas: 1. Identificação: são reconhecidas as funções que, devido à algum contexto de chamada, podem se beneficiar da clonagem. 2. Clonagem: é criado um clone para cada função marcada na etapa anterior. 3. Substituição: chamadas promissoras são substituı́das por chamadas da função clonada. Findas essas três etapas, aplicamos sobre o programa transformado as otimizações disponı́veis em LLVM -O2. São essas otimizações que irão, efetivamente, polir o código da função clonada. Por exemplo, ao eliminarmos o valor de retorno de uma função, nós não removemos as computações necessárias ao seu cálculo. Deixamos tal tarefa a cargo de LLVM -O2. Durante nossos experimentos, nós omitimos a integração de procedimentos (inlining) desse conjunto de otimizações. Fizê-mo-lo porque a integração de procedimentos torna difı́cil medir os ganhos obtidos por nossa otimização, uma vez que muitas das chamadas das funções originais e clonadas são removidas do programa. Finalmente, antes de produzirmos um executável, nós eliminamos os chamados clones órfãos. Se todas as chamadas de uma função clonada forem promissoras, então a versão original daquela função deixará de ser alcançável. Tais funções – denominadas órfãs – são eliminadas nessa etapa final. Variação no tempo de execução. A figura 2 mostra a variação no tempo de execução dos programas devido a nossas otimizações. Os tempos de execução foram obtidos com um intervalo de confiança de 95.0%, tendo sido coletadas dez amostras por programa examinado. Estamos comparando os programas obtidos após a aplicação do último estágio mostrado na figura 1, com os programas obtidos via a aplicação de todas as otimizações presentes em LLVM -O2. A média geométrica de ganho, devido a distinção de apontadores, foi de 1.59%. Nosso melhor resultado, nesse caso, foi 6.10% obtido sobre 483.xalancbmk, e nosso pior número foi -1,83% em 453.povray. Nós não pudemos obter resultados conclusivos com a eliminação de valores de retorno: a maior parte de nossos resultados ficaram dentro de uma margem de variação de -1.0% e +1.0%. Especulamos que esses resultados tı́midos devem-se ao fato de estarmos testando nossas otimizações sobre os programas disponı́veis em SPEC CPU 2006. 103 Figura 2. Variação no tempo de execução dos benchmarks devido à distinção de apontadores. Barras representam percentual de ganhos entre LLVM -O2 mais nossa otimização, e LLVM -O2 sem ela. Quanto maior a barra, maior o ganho conseguido por nossa otimização. Esses programas foram escritos por profissionais experts, e vêm sendo gradualmente melhorados desde longa data. Em outros benchmarks menos otimizados pudemos registrar ganhos maiores. Por exemplo, a companhia Adobe possui uma coleção de seis programas usados em testes de desempenho publicamente disponı́veis em http://stlab.adobe.com/performance/. Ao aplicarmos a distinção de apontadores sobre esses programas, pudemos obter um ganho de 31.20% em um deles, loop unroll.c. Registramos também ganhos em outros três: simple types loop.c (3.81%), functionobjects.c (3.86%) e simple types const.c (4.15%). Decidimos averiguar o porquê de a eliminação de valores de retorno não surtir maior efeito nos programas encontrados em SPEC CPU 2006. Com tal intuito, observamos que muitas funções clonadas usam o valor de retorno somente para indicar sucesso na execução. Dessa forma, muitos clones tiveram somente a instrução de retorno, por exemplo, “ret 1”, substituı́da por “ret void”. 4. Trabalhos Relacionados A ideia de clonar funções para que otimizações dependentes de contexto possam ser aplicadas sobre o seu código não é nova. Em seu recente livro texto, Grune et al., por exemplo, descrevem a clonagem como uma forma de aumentar o alcance da propagação de constantes [Grune et al. 2012, pg.325]. Os algoritmos mencionados por Grune et al. parecem ter sido inicialmente propostos por Mary Hall em sua dissertação de doutorado [Hall 1991, Cp.5]. Nesse caso, a clonagem é comumente chamada especialização de código. A técnica de Hall pode ser descrita como especialização estática. A contraparte dinâmica existe também. Costa et al. mostraram como clonar funções no contexto 104 da compilação just-in-time para realizar a propagação de constantes em código especializado [de Assis Costa et al. 2013]. Ainda assim, é surpreendentemente difı́cil encontrar, na literatura de linguagens de programação, discussões sobre a clonagem de funções para a implementação de otimizações dependentes de contexto. Compiladores industriais, tais como icc e LLVM não utilizam a clonagem. Os compiladores gcc e open64 podem realizar a clonagem de uma função que possui somente um sı́tio de invocação, e que recebe constantes como parâmetros. 5. Conclusão e Trabalhos Futuros Neste trabalho, propomos otimizações especı́ficas capazes de tirar proveito do contexto onde funções são chamadas para gerar um código mais eficiente. Duas otimizações foram implementadas e testadas. A primeira delas lida com funções cujo valor de retorno não é usado. A segunda promove a distinção dos apontadores passados como parâmetros de funções. Para aplicar nossas otimizações somente em contextos promissores, recorremos à clonagem e especialização de funções. Nossos experimentos mostraram que as transformações propostas são capazes de aumentar a eficiência de programas, ainda que aplicadas sobre os nı́veis mais altos de otimização de um compilador industrial. Pretendemos desenvolver outras otimizações baseadas em clonagem que sejam sensı́veis ao contexto de chamada das funções. Como futuras otimizações, vislumbramos a substituição de parâmetros por constantes e a eliminação de escritas desnecessárias em parâmetros. Todo o código utilizado em nossos experimentos encontra-se publicamente disponı́vel na página https://code.google.com/p/clone-based-opts/. Referências Andersen, L. O. (1994). Program Analysis and Specialization for the C Programming Language. PhD thesis, DIKU, University of Copenhagen. Appel, A. W. and Palsberg, J. (2002). Modern Compiler Implementation in Java. Cambridge University Press, 2nd edition. de Assis Costa, I. R., Alves, P. R. O., oolmes13 Henrique Nazare Santos, and Pereira, F. M. Q. (2013). Just-in-time runtime specialization. In CGO, pages 1–11. ACM. Grune, D., van Reeuwijk, K., Jacobs, H. E. B. C. J. H., and Langendoen, K. (2012). Modern Compiler Design. Springer, 2nd edition. Hall, M. W. (1991). Managing interprocedural optimization. PhD thesis, Rice University, Houston, TX, USA. UMI Order No. GAX91-36029. Keith D. Cooper, L. T. (2012). Engineering a Compiler. Morgan Kaufmann, 2nd edition. Lattner, C. and Adve, V. S. (2004). LLVM: A compilation framework for lifelong program analysis & transformation. In CGO, pages 75–88. IEEE. Lhoták, O. and Hendren, L. (2006). Context-sensitive points-to analysis: is it worth it? In CC, pages 47–64. Springer-Verlag. Shivers, O. (1988). Control-flow analysis in scheme. In PLDI, pages 164–174. ACM. Whaley, J. and Lam, M. S. (2004). Cloning-based context-sensitive pointer alias analysis using binary decision diagrams. In PLDI, pages 131–144. ACM. 105 Uma Proposta para Geração Automática de Testes para Linhas de Produtos de Software Sensíveis ao Contexto Ítalo Linhares de Araújo1,∗ Orientadores: Rossana Maria de Castro Andrade 1,†, Pedro de Alcântara dos Santos Neto2 1 Grupo de Redes de Computadores, Engenharia de Software e Sistemas (GREat) Mestrado e Doutorado em Ciência da Computação (MDCC) Universidade Federal do Ceará (UFC) Fortaleza, Ceará, Brasil 2 Laboratório de Engenharia de Software e Informática Industrial (EaSII) Departamento de Computação Universidade Federal do Piauí (UFPI) Teresina, Piauí, Brasil {italoaraujo, rossana}@great.ufc.br, [email protected] Nível: Mestrado Ano de ingresso: 2012 Previsão de conclusão: fevereiro de 2014 Data da aprovação: abril de 2013 Evento Associado: SBES Resumo. Uma Linha de Produtos de Software Sensível ao Contexto (LPSSC) tem como objetivo desenvolver aplicações sensíveis ao contexto. O teste em uma LPSSC agrega os desafios de se testar uma LPS e uma aplicação sensível ao contexto. Para auxiliar a lidar com esses desafios, a geração dos testes pode ser automatizada e pode ser feita a partir de Casos de Uso Textuais (CUT) da LPSSC. Na literatura, poucas soluções foram encontradas para teste em LPSSC, uma delas é o método ChAPTER que gera cenários de teste para uma LPSSC a partir de um CUT, mas que não gera testes executáveis. Este trabalho possui então como objetivo estender o nível de automação já disponibilizado pelo ChAPTER para permitir a geração automática da estrutura necessária para a execução de testes em uma LPSSC. Palavras-chave: aplicações sensíveis ao contexto, linha de produtos de software, teste de software ∗ Bolsista de Mestrado da CAPES Bolsista do CNPq de Produtividade em Desenvolvimento Tecnológico e Extensão Inovadora (DT) 2 com o número de processo 314021/2009-4 † 106 1. Caracterização do Problema As Linhas de Produtos de Software (LPS) tem sido bastante utilizadas por empresas que desejam reutilizar artefatos e para obter economia de tempo e custos durante a produção de aplicações. Segundo o SEI (Software Engineering Institute), uma LPS é um conjunto de sistemas de software que compartilham características comuns, satisfazendo as necessidades específicas de um segmento particular do mercado e que é desenvolvido a partir de artefatos comuns [Northrop 2002]. Quando uma LPS tem como objetivo produzir aplicações sensíveis ao contexto, que se adaptam de acordo com o contexto atual do usuário [Du e Wang 2008], tem-se uma LPS Sensível ao Contexto (LPSSC) [Fernandes et al. 2011]. No desenvolvimento de software, uma das formas de garantir qualidade a uma aplicação é por meio de testes, os quais são considerados uma das etapas mais onerosas do processo [Shamsoddin-motlagh 2012, Myers et al. 2011] e que chegam a consumir 50% do tempo durante o desenvolvimento de uma aplicação [Myers et al. 2011]. Esses valores podem aumentar ao se testar uma LPSSC devido à complexidade das aplicações sensíveis ao contexto e dos desafios agregados ao se desenvolver uma linha de produto. Em relação ao desenvolvimento baseado em LPS, é importante considerar ainda que um erro na documentação da linha pode acarretar em erros nos diversos produtos gerados [Santos 2013] e, por isso, é importante garantir a correção dos defeitos a um custo mínimo. Assim, a busca por defeitos pode ser feita ainda na fase de requisitos. A automação da geração dos testes é uma forma de reduzir os custos e pode ser feita a partir de casos de uso, uma vez que estes descrevem o comportamento do sistema. Com base nisso, uma pesquisa foi realizada para buscar trabalhos que tivessem como objetivo automatizar alguma etapa necessária para a execução de testes em aplicações comuns e sensíveis ao contexto, em LPS e LPSSC. Foram encontrados alguns trabalhos relacionados a estes temas [Schnelte 2009, Siqueira 2010, Bertolino e Gnesi 2003], porém apenas um [Santos 2013] tratava da automação de testes para LPSSC. Mais detalhes desses trabalhos relacionados podem ser encontrados na Seção 5. O método ChAPTER (Context Aware software Product line TEsting geneRation method) [Santos 2013] automatiza a geração de cenários de teste para uma LPSSC baseado nas informações presentes em um caso de uso textual (CUT). Esse método possui duas limitações. A primeira delas é em relação a descrição dos casos de uso que é feita em linguagem natural, o que dificulta a geração automática de testes, dada a ambiguidade inerente a esse tipo de descrição. Uma solução alternativa para é o uso de uma Linguagem Natural Controlada (LNC), que é uma linguagem natural com restrição no vocabulário e na gramática [Schwitter e Tilbrook 2006, Schnelte 2009]. A segunda limitação está relacionada aos cenários de teste gerados, os quais são uma representação abstrata de um teste [Somé e Cheng 2008] e, por isso, não é possível executá-los. Existe, portanto, a necessidade de uma evolução do ChAPTER para diminuir a ambiguidade na descrição dos CUT bem como tornar os cenários de testes executáveis. Este trabalho propõe estender o método desenvolvido por Santos (2013) de maneira que permita a geração automática da estrutura necessária para a execução de testes em uma LPSSC. Para isso, as informações necessárias para tal geração são extraídas de CUTs de uma LPSSC. Os casos de uso são descritos utilizando a LNC a ser definida neste tra- 107 balho, além de existir um arcabouço específico para transformar o entendimento do caso de uso dos produtos da linha em procedimentos e casos de teste associados que exercitem tais casos de uso. 2. Fundamentação Teórica Essa seção trata de alguns conceitos relacionados à aplicações sensíveis ao contexto, linha de produto de Software e teste de software. Segundo Dey (2001) [Dey 2001], contexto é qualquer informação que pode ser usada para caracterizar a situação de qualquer entidade, sendo que uma entidade pode ser uma pessoa, lugar ou objeto que pode ser relevante para a interação entre o usuário e a aplicação, incluindo o próprio usuário e a aplicação. Portanto, uma aplicação sensível ao contexto deve mudar dinamicamente o seu comportamento segundo o contexto atual do usuário. Uma informação de contexto pode estar relacionada a localização atual do usuário, por exemplo, no GREatTour [Marinho et al. 2010], que é uma aplicação desenvolvida para guiar os visitantes no laboratório do GREat 1 (Grupo de Redes de Computadores, Engenharia de Software e Sistemas). Nela, são exibidas informações (e.g. textos, imagens e vídeos) associadas ao ambiente em que o visitante se encontra. No caso de uma LPS, dois processos de desenvolvimento estão presentes: o Desenvolvimento do Núcleo de Artefatos e o Desenvolvimento do Produto [Northrop 2002]. No Desenvolvimento do Núcleo de Artefatos é definido o escopo da linha além de criar os artefatos comuns a todos os produtos da linha. No Desenvolvimento do Produto, os produtos e os artefatos específicos a cada aplicação são gerados sempre baseados nos artefatos gerados no primeiro processo. Por fim, em se tratando do teste de software, este segundo Myers et al. (2011), é um processo ou conjunto de processos que tem como objetivo garantir uma aplicação faça aquilo que deve fazer e não execute aquilo para o qual não foi planejada. Portanto, ele verifica se o software está funcionando corretamente garantindo, assim, qualidade às aplicações criadas. Testes podem ser gerados automaticamente com base nas informações contidas em casos de uso textuais. Os casos de uso descrevem o comportamento do sistema, porém, geralmente, essa descrição é feita em linguagem natural. Isso dificulta a geração automática de testes, pois as linguagens naturais podem ser ambíguas e imprecisas. Uma alternativa para o uso de linguagem natural é o uso de uma linguagem natural controlada (LNC). Esse tipo de linguagem é similar a uma linguagem natural, porém contém restrições no vocabulário e na gramática [Schnelte 2009, Schwitter e Tilbrook 2006]. Quando se trata então de testes em uma LPSSC, desafios referentes ao teste em uma LPS e referentes ao teste em aplicações sensíveis ao contexto são levados em conta. Devem ser considerados testes nos artefatos criados na etapa de Desenvolvimento do Núcleo de Artefatos e também dos produtos criados na etapa de Desenvolvimento de Produtos [Pohl et al. 2010]. Além disso, no caso das aplicações sensíveis ao contexto é preciso considerar as questões associadas a captura de informações do ambiente bem como a adaptação dinâmica da aplicação. 1 http://www.great.ufc.br/ 108 3. Objetivos, Resultados Esperados e Contribuições Este trabalho tem como objetivo estender o método ChAPTER de maneira que seja possível gerar casos de teste para uma LPSSC. Para isso, o método deve ser capaz de interpretar casos de uso descritos em uma LNC, que também deve ser definida neste trabalho, e a partir dessa interpretação deve gerar casos de teste. Um exemplo de uso da linguagem ocorre no seguinte passo de um caso de uso: "O Usuário digita o login e a senha.". Ao encontrar essa frase, o método deve identificar o ator envolvido na operação, a operação a ser executada, e, se houver, campos a serem preenchidos. No caso deste passo, o ator é "Usuário", a operação é “digita” que diz que informações devem ser inseridas e que os campos “login” e “senha” devem ser preenchidos. Com base nisso, o método deve ser capaz de analisar e interpretar uma frase que utiliza a LNC para gerar automaticamente a estrutura necessária para a execução do teste. Assim, os seguintes resultados são esperados ao final deste trabalho: • Definição de uma Linguagem Natural Controlada para descrever os casos de uso de uma Linha de Produtos de Software Sensível ao Contexto. As restrições da LNC devem retirar a ambiguidade e imprecisão de uma linguagem natural, facilitando, assim, o cumprimento do objetivo apresentado no próximo item desta Seção; • Extensão do método ChAPTER, definido por [Santos 2013] e que será melhor descrito na Seção 5, para facilitar a criação da estrutura necessária para a execução de testes em LPSSC, sendo essa estrutura composta de casos de teste e outros artefatos necessários. Além disso, a ferramenta ToChAPTER 2 , que implementa o método, deve ser evoluída para permitir a extensão do método. Este trabalho tem como principal contribuição o apoio ferramental para a geração de testes para LPSSCs, garantindo, assim, a melhoria da qualidade de aplicações sensíveis ao contexto que são construídas utilizando LPS. 4. Estado Atual do Trabalho Para atingir os objetivos do trabalho, as seguintes etapas devem ser executadas: (i) identificação e estudo de LNCs existentes; (ii) identificação e estudo de métodos para geração de testes a partir de casos de uso; (iii) proposta da linguagem natural controlada; (iv) avaliação da LNC; (v) definição do método para geração da estrutura necessária para a execução dos testes; (vi) extensão do método ChAPTER para permitir a geração da estrutura do teste; (vii) implementação de uma ferramenta de apoio; e (viii) avaliação do método para geração de testes. Uma etapa, a (i), está concluída, as etapas (ii) e (v) encontram-se em execução e a etapa (iii) está em fase final de execução. As etapas (iv), (vi), (vii) e (viii) ainda não foram executadas. Como apresentado, foi concluído o estudo de LNCs existentes, e já foi iniciado a identificação e estudo dos métodos para geração automática de testes a partir de casos de uso. Assim, teve início a definição da LNC, e, em paralelo, teve início a definição do método para gerar os testes para LPSSC a partir de um CUT que utiliza a LNC. 2 http://pesquisa.great.ufc.br:8080/tochapter 109 5. Trabalhos Relacionados Nesta Seção são apresentados os trabalhos relacionados a esta pesquisa que tem como objetivo apoiar a atividade de steste, como os trabalhos de [Santos 2013, Siqueira 2010, Schnelte 2009, Bertolino e Gnesi 2003]. O trabalho de Santos (2013) definiu um template de caso de uso textual para inserir variabilidade e informação de contexto, o CAPLUC (Context Aware software Product Line Use Case), e, a partir desse template foi possível gerar cenários de teste para uma LPSSC. O ChAPTER, método também definido por Santos (2013), permite a geração dos cenários de teste a partir de casos de uso textuais. Os cenários são gerados em três níveis. Um desses níveis corresponde a testes na parte de Desenvolvimento do Núcleo de Artefatos. O segundo nível gera cenários específicos para o produto, e o terceiro nível gera para as possíveis configurações de um produto. O trabalho de [Siqueira 2010] definiu uma ferramenta, a TaRGeT (Test and Requirements Generation Tool), que tem como objetivo gerar casos de teste a partir de casos de uso. O caso de uso utilizado para a geração de casos de teste teve seu template definido pelo autor e permite informar ações do usuário, do sistema e pré-condições. Schnelte (2009) propôs um método para geração de casos de teste a partir de uma linguagem natural controlada. Ela utiliza estados com sinais (valores) definidos no vocabulário da LNC. O método tenta gerar um caminho entre o estado inicial e o estado que se deseja alcançar [Schnelte 2009]. Bertolino e Gnesi (2003) definiram um método para geração de cenários de teste, o PLUTO (Product Line Use Case Test Optimization) [Bertolino e Gnesi 2003]. Esse método utiliza o template PLUC (Product Line Use Case) e a descrição em linguagem natural como insumos para a automação da geração dos cenários de teste. Diante do que foi apresentado, percebe-se que os trabalhos não propõem uma abordagem para geração da estrutura necessária para a execução dos testes para uma LPSSC. Apesar do trabalho desenvolvido por Santos (2013) automatizar parte do processo, ainda é necessário a intervenção humana. 6. Avaliação dos Resultados A Linguagem Natural Controlada a ser definida neste trabalho deve ser avaliada com o intuito de assegurar que a mesma mantém a compreensão da descrição dos casos de uso ao compará-la com a descrição feita utilizando linguagem natural. Para isso, deve ser realizado um experimento [Wohlin et al. 2000]. A extensão do método ChAPTER também deve ser avaliada por meio de experimentos para avaliar se os testes criados reduzem o tempo gasto para criá-los manualmente e se há uma maior cobertura do que o processo manual. Referências Bertolino, A. e Gnesi, S. (2003). Use case-based testing of product lines. volume 28, pp 355–358, New York, NY, USA. ACM. Dey, A. K. (2001). Understanding and using context. Personal and ubiquitous computing, 5(1):4–7. 110 Du, W. e Wang, L. (2008). Context-aware application programming for mobile devices. In Proceedings of the 2008 C3S2E conference, C3S2E ’08, pp 215–227, New York, NY, USA. ACM. Fernandes, P., Werner, C., e Teixeira, E. (2011). An Approach for Feature Modeling of Context-Aware Software Product Line. Journal of Universal Computer Science, 17(5):807–829. Marinho, F. G., Costa, A. L., Lima, F. F. P., Neto, J. B. B., Filho, J. B. F., Rocha, L., Dantas, V. L. L., Andrade, R. M. C., Teixeira, E., e Werner, C. (2010). An Architecture Proposal for Nested Software Product Lines in the Domain of Mobile and ContextAware Applications. 2010 Fourth Brazilian Symposium on Software Components, Architectures and Reuse, pp 51–60. Myers, G., Sandler, C., e Badgett, T. (2011). The Art of Software Testing. ITPro collection. Wiley. Northrop, L. (2002). Sei’s software product line tenets. Software, IEEE, 19(4):32 – 40. Pohl, K., Böckle, G., e van der Linden, F. (2010). Software Product Line Engineering: Foundations, Principles and Techniques. Springer. Santos, I. S. (2013). Um ambiente para geração de cenários de testes para linhas de produto de software sensíveis ao contexto. Dissertação de Mestrado, Universidade Federal do Ceará. pp. 1–133. Schnelte, M. (2009). Generating test cases for timed systems from controlled natural language specifications. In Secure Software Integration and Reliability Improvement, 2009. SSIRI 2009. Third IEEE International Conference on, pp 348–353. Schwitter, R. e Tilbrook, M. (2006). Annotating websites with machine-processable information in controlled natural language. In Proceedings of the second Australasian workshop on Advances in ontologies - Volume 72, AOW ’06, pp 75–84, Darlinghurst, Australia, Australia. Australian Computer Society, Inc. Shamsoddin-motlagh, E. (2012). A review of automatic test cases generation. International Journal of Computer Applications, 57(13):25–29. Published by Foundation of Computer Science, New York, USA. Siqueira, H. L. F. (2010). Target scripts generation: Um plug-in de geração automática de scripts de teste. Trabalho de Conclusão de Curso. Universidade Federal de Pernambuco. Somé, S. S. e Cheng, X. (2008). An approach for supporting system-level test scenarios generation from textual use cases. In Proceedings of the 2008 ACM symposium on Applied computing, SAC ’08, pp 724–729, New York, NY, USA. ACM. Wohlin, C., Runeson, P., Höst, M., Ohlsson, M. C., Regnell, B., e Wesslén, A. (2000). Experimentation in software engineering: an introduction. Kluwer Academic Publishers, Norwell, MA, USA. 111 RecCloud: Um Sistema de Recomendação Baseado em Nuvem Ricardo Batista Rodrigues1 (Aluno), Vinicius C. Garcia1 (Orientador), Rodrigo Assad2 (Colaborador), Frederico A. Durão3 (Co-orientador) Trabalho de Mestrado 1 Centro de Informática – Universidade Federal de Pernambuco (Cin - UFPE) Av. Jornalista Anibal Fernandes, s/n – Cidade Universitária, 50.740-560 – Recife, Pernambuco, Brasil. 2 Universidade Federal Rural de Pernambuco (UFRPE) Rua Dom Manoel de Medeiros, s/n. Campus Dois Irmãos, 52.171-900 – Recife Pernambuco, Brasil. 3 Instituto de Matemática – Universidade Federal da Bahia (UFBA) Av. Adhemar de Barros, S/N, Campus de Ondina, 40170-110 Salvador, Bahia, Brasil. {rbr, vcg}@cin.ufpe.br, [email protected], [email protected] Ano de Ingresso no Programa de Mestrado: 2012 Época Esperada de conclusão: Fevereiro/2014 Etapas já Concluídas: Revisão da Literatura. Simpósio Brasileiro de Engenharia de Software - (SBES) Resumo. O crescimento no volume de dados proporcionado pelo desenvolvimento computacional já ultrapassou a capacidade cognitiva dos usuários em analisar grandes massas de dados. Acompanhando essa tendência, surgiram os ambiente de armazenamento de dados em nuvem, que dentre outras vantagens oferecem uma grade capacidade de armazenamento. Este artigo apresenta a pesquisa e o desenvolvimento de um mecanismo de recomendação de arquivos em um ambiente de armazenamento de dados na nuvem, utilizando técnicas de filtragem baseada em conteúdo. O sistema recomendará ao usuário arquivos que sejam similares aos arquivos em que ele demostre interesse em suas interações no ambiente. Este trabalho tem como principal contribuição a utilização de fatores da nuvem, que utilizados na geração de recomendações podem inferir em ganhos consideráveis em termos de disponibilidade de arquivos recomendados e economia de tempo por parte do usuário na busca por novos conteúdos, e a filtrar conteúdos relevantes em meio à imensidão de dados armazenados na nuvem. Palavras-Chave: Sistemas de recomendação, computação em nuvem, filtragem baseada em conteúdo. 112 1. Introdução Segundo Billsus e Pazzani, (2009) e Phelan et al., (2009), Sistemas de Recomendação (SR) são softwares e técnicas que fornecem sugestões de itens para usuários. Esses sistemas fazem parte de nossas vidas, diariamente nós nos deparamos com recomendações via e-mail ou em páginas na web. SRs ajudam a superar a sobrecarga de informação fornecendo sugestões personalizadas com base em um histórico de preferências do usuário. Muitas lojas online e plataformas oferecem serviços de recomendação como, por exemplo, Amazon1 e BarnesAndNoble2 [Melville et al, 2002]. Existem duas abordagens predominantes na construção de SR – Filtragem Colaborativa (CF) e Filtragem Baseada em Conteúdo (CB). Sistemas CF recomendam itens que são similares às características do usuário como, por exemplo, o seu perfil em uma rede social. Sistemas CB recomendam ao usuário itens semelhantes àqueles em que ele demonstrou interesse em experiências anteriores. Para tanto, o sistema analisa as descrições dos conteúdos dos itens avaliados pelo usuário para montar o seu perfil, o qual é utilizado para filtrar os demais itens da base (Blanco et al. (2008), Ricci et al. (2011), Phelan et al. (2009)). Com o advento da computação em nuvem, surgiram os sistemas cloud storage, que possibilitam aos seus usuários armazenar arquivos na nuvem. Com o crescimento da utilização destes sistemas, a massa de dados armazenados na nuvem se tornou humanisticamente impossível de ser processada, implicando na ocultação de informações relevantes aos usuários. Eles deixam de descobrir novos conteúdos por não disporem de meios eficientes que os auxilie na filtragem de dados em busca de conhecimento relevante e que atenda suas expectativas. Diante deste cenário, sistemas de recomendação se tornam uma alternativa para auxiliar os usuários na tomada de decisão por qual arquivo escolher e a filtrar informações relevantes em meio a uma imensidão de dados. Com uma grande massa de dados públicos disponível e armazenada em nuvem, é importante que o usuário possa encontrá-lo com facilidade. Com isso, esta pesquisa tem como objetivo propor uma abordagem para a recomendação de arquivos baseada em fatores oriundos da nuvem e utilizando a técnica de recomendação baseada em conteúdo. O mecanismo proposto auxiliará os usuários amenizando e contribuindo na difícil tarefa de buscar novos conteúdos e a filtrar conhecimento relevante em meio a uma imensa massa de dados armazenados na nuvem. Este artigo está organizado da seguinte forma: seção 2 apresenta trabalhos relacionados. A seção 3 apresenta o SR proposto. Na seção 4 são explanadas as contribuições da pesquisa. Na seção 5 é apresentado o estado atual desta pesquisa. Na seção 6 é apresentada a avaliação e os resultados esperados. Finalmente, a seção 7 apresenta as conclusões e os trabalhos futuros desta pesquisa. 2. Trabalhos Relacionados Existem trabalhos na literatura que discutem questões a respeito de sistemas de recomendações na nuvem. Nesta seção, serão apresentados alguns deles, enfatizando a similaridade e as diferenças em relação ao modelo de recomendação proposto nesta pesquisa. 1 2 http://www.amazon.com/ http://www.barnesandnoble.com/ 113 Lee et al. (2010) apresentam uma proposta de SR que utiliza dados armazenados na nuvem para proverem suas recomendações, distinguindo-se da proposta deste trabalho que além de recomendar arquivos armazenados na nuvem, tem como objetivo utilizar fatores baseados na nuvem para garantir a disponibilidade dos arquivos recomendados aos usuários. Lai et al. (2011) apresentam o trabalho que mais se aproxima da proposta desta pesquisa. O trabalho mencionado propõe um SR de programas de TV em nuvem, com objetivo principal de oferecer um sistema escalável, que tenha uma alta taxa de disponibilidade para o sistema. O SR proposto nesta pesquisa utiliza fatores da nuvem para gerar suas recomendações, com o objetivo de recomendar arquivos que estejam disponíveis na nuvem e a economia do tempo gasto para download de arquivos recomendados, e que as recomendações atendam as preferências dos usuários. 3. RecCloud Esta pesquisa surgiu a partir da observação de um problema real, vivenciado por usuários de ambientes de armazenamento de dados na nuvem. Com a evolução desses sistemas, muitos usuários migraram seus dados para a nuvem, criando uma grande massa de dados e tornando o processo de filtragem de conteúdo trabalhoso, demandando certa quantidade de tempo. O tempo gasto por usuário em busca de novos conhecimentos e filtragem de conteúdo relevante pode ser amenizado com a utilização de um sistema de recomendação, que recomende arquivos similares a seus interesses. Diante deste contexto, propomos um modelo de recomendação aplicado a ambientes de armazenamento de dados na nuvem, que seja capaz de recomendar ao usuário arquivos que sejam similares a suas preferências e que atenda a fatores da nuvem. O SR proposto nesta pesquisa foi desenvolvido em um ambiente real de armazenamento de dados na nuvem, o “Ustore3”. A partir da pesquisa e observação de ambientes de armazenamento de dados na nuvem, propomos cinco fatores, apresentados a seguir: 3 Similaridade: este fator representa a similaridade de um arquivo na nuvem com as preferências do usuário. As preferências do usuário são representadas pelos arquivos adicionados em sua conta no ambiente na nuvem. A similaridade entre as preferências do usuário com o conteúdo do arquivo recomendado é obtida pela técnica de similaridade do cosseno. Essa técnica é a diferença angular entre dois vetores através do cálculo do cosseno do ângulo entre eles, independente do tamanho deles (Yates e Neto, 1999). Disponibilidade: este fator representa a disponibilidade do servidor em que o arquivo recomendado está armazenado, sendo assim um arquivo somente poderá ser recomendado se o fator Disponibilidade for maior que 0. Esse fator garante que um arquivo somente será recomendado se ele estiver disponível para download. Taxa de Download: este fator representa a taxa disponível para a realização de download de um arquivo recomendado. Desta forma, um arquivo somente deve ser recomendado se esse fator for superior a 0. http://usto.re/ 114 Quantidade de Download: este fator representa a importância social de um arquivo candidato a ser recomendado. Neste trabalho, a importância social de um arquivo na nuvem é medida de acordo com a quantidade de downloads de um determinado arquivo. Por exemplo, um arquivo A já teve 20 downloads e um arquivo B similar ao arquivo A já teve 10 downloads realizados. Desta forma, o arquivo A deverá ser recomendado, por ter maior importância social na rede. Tamanho do Arquivo: este fator representa o tamanho do arquivo recomendado ao usuário. Desta forma, se um arquivo tiver o seu tamanho superior aos demais similares, então, este arquivo não deve ser recomendado e sim um similar seu de menor tamanho. Por exemplo, um arquivo A tem o seu tamanho igual a 4 Gigabytes, outro arquivo B que é similar ao arquivo A, tem tamanho 1 GigaByte. Neste cenário, o arquivo que deverá ser recomendado ao usuário é o arquivo B, este proporcionará ao usuário uma economia em tempo de download em referência ao tempo que seria gasto no download do arquivo A. 4. Contribuições O objetivo principal desta pesquisa é propor um mecanismo de recomendação que utilize fatores da nuvem na geração de suas recomendações e que proporcionem ganhos em termos de disponibilidade dos arquivos recomendados, gerando economia no tempo gasto no download de um arquivo recomendado e filtragem de conteúdo relevante. Esta pesquisa, além de atender os requisitos da nuvem em suas recomendações, visa atender as preferências dos usuários, com base na similaridade do conteúdo do arquivo recomendado com o conteúdo de arquivos em que o usuário demostre interesse. 5. Estado Atual O trabalho encontra-se em estado inicial de execução de experimentos, com o objetivo de avaliar e validar o modelo proposto. A primeira etapa deste trabalho consistiu na revisão da literatura, com o objetivo de melhor entender a área, fundamentar a proposta do projeto, mapear trabalhos relacionados, e montar o referencial desta pesquisa. A revisão da literatura se fundou em um processo de ampla pesquisa à procura de artigos publicados, combinando pesquisa automática e manual para aumentar a cobertura. A busca automática foi realizada em quatro fontes de pesquisa: IEEEXplore Digital Library4, ACM Digital Library5, Elsevier Science Direct6, Elsevier Scopus7. A busca manual foi realizada nos anais da conferencia “The ACM Conference Series on Recommender Systems8”, por ser uma conferência de grande destaque na área desta pesquisa. Os trabalhos encontrados foram analisados com o objetivo de identificar sua relevância e contribuição para esta pesquisa. A partir da revisão da literatura, propomos fatores oriundos da nuvem, além de fornecer requisitos necessários para a implementação do SR proposto. Na segunda etapa, decorreu o desenvolvimento do sistema de recomendação proposto. 4 http://ieeexplore.ieee.org/Xplore/guesthome.jsp http://dl.acm.org/ 6 http://www.sciencedirect.com/ 7 http://www.scopus.com/home.url 8 http://recsys.acm.org/ 5 115 6. Avaliação dos Resultados e Resultados Esperados Os resultados obtidos neste projeto são formados pelo referencial bibliográfico do projeto, que foi gerado como resultado da revisão da literatura e permitiu a formatação da proposta da pesquisa, assim como o levantamento de requisitos necessários para o desenvolvimento do SR proposto. Como resultado, obtivemos um mecanismo de recomendação que atende os requisitos da nuvem e de preferências dos usuários. Para avaliação das recomendações geradas pelo SR desenvolvido, serão realizados experimentos em um ambiente real de armazenamento de dados na nuvem (Ustore) com o objetivo de avaliar as recomendações geradas, o tempo gasto no download de arquivos recomendados, o desempenho do SR (o tempo de geração de uma recomendação), e as recomendações em referência às preferências elícitas pelos usuários. Os experimentos serão realizados em dois cenários distintos, o primeiro cenário consiste no SR proposto nesta pesquisa e o segundo cenário consiste em um sistema de recomendação baseado em conteúdo, que gere recomendações baseadas apenas na similaridade de conteúdo dos arquivos recomendados com as preferencias dos usuários. 7. Considerações Finais Este artigo apresentou o projeto RecCloud, um sistema de recomendação baseado em conteúdo e que utiliza fatores da nuvem. O projeto se encontra em fase inicial de validação, por meio de experimentos que serão realizados em um ambiente real de armazenamento de dados na nuvem. O objetivo é avaliar o modelo proposto e comparar os resultados obtidos com avaliações de recomendações baseadas apenas na similaridade do conteúdo do arquivo recomendado. A partir deste processo, objetivamos obter como resultado um modelo válido para a implementação de sistemas de recomendações em ambientes de armazenamento de dados na nuvem que atendam a fatores da nuvem. 7. Agradecimentos Este trabalho foi apoiado [em parte] pelo Instituto Nacional de Ciência e Tecnologia para Engenharia de Software (INES9), financiado pelo CNPq e FACEPE, processos 573964/2008-4 e APQ-1037-1.03/08. 8. Referências Billsus, D., Pazzini, M. J., (2009), “A Personal news agent that talks, learns and explains”, Em: Proceedings of the Third International Conference on Autonomous Agents (AGENT’99), ACM, New York, NY, USA, 268-275, DOI= http://doi.acm.org/10.1145/301136.301208. Blanco, Fernandez Y., Pazos, Arias J. J., G.S.A., Ramos, Cabrer M., Lopes, Norez, (2008), “Providing Entertainment by Content-based Filtering and Semantic Reasoning in Intelligent Recommender Systems”, IEEE Transactions on Consumer Electronics 54(2), 727–735. DOI= 10.1109/TCE.2008.4560154. Yates, R. Baeza, Neto, B. Ribeiro, (1999), Modern Information Retrieval. Addison Wesley, Maio de 1999. 9 http://www.ines.org.br 116 Lai, Chin-Feng, Jui-Hung Chang, Chia-Cheng Hu, Yueh-Min Huang, and Han-Chieh Chao (2011), CPRS: A cloud-based program recommendation system for digital TV platforms. Future Gener. Comput. Syst. 27, 6 (Junho de 2011), 823-835. DOI= http://dx.doi.org/10.1016/j.future.2010.10.002. Lee, SeungGwan; Daeho Lee; Sungwon Lee, (2010), "Personalized DTV program recommendation system under a cloud computing environment," Consumer Electronics, IEEE Transactions, vol.56, no.2, 1034-1042, DOI= 10.1109/TCE.2010.5506036. Melville, Prem, Raymod J. Mooney, Ramadass Nagarajan, (2002), Content-boosted collaborative filtering for improved recommendations. In Eighteenth national conference on Artificial intelligence. American Association for Artificial Intelligence, Menlo Park, CA, USA, 187-192. Phelan, Owen, Kevin McCarthy, Barry Smyth, (2009), Using twitter to recommend real-time topical news. Proceedings of the third ACM conference on Recommender systems (RecSys '09). ACM, New York, NY, USA, 385-388. DOI= http://doi.acm.org/10.1145/1639714.1639794. Ricci, Francesco, Rokach, Lior, Shapira, Bracha, Kantor, Paul B., (2011), “Recommender System Handbook”, Springer New York Dordrecht Heidelberg London. 117 V a l i d a c¸ a ˜ o E x p e r i m e n t a l d a A b o r d a g e m S M a r t y p a r a G e r e n c ia m e n to d e V a r ia b ilid a d e e m L in h a d e P r o d u to d e S o ftw a r e A n d e r s o n S . M a r c o lin o , E d s o n A . O liv e ir a J u n io r 1 P r o g r a m a d e P o ´ s - G r a d u a c¸ E D e p a rta m e n to d e C E P 8 a˜ o e m C i eˆ n c i a d a C o m s t a d u a l d e M a r i n g a´ ( U I n f o r m a´ t i c a , A v . C o l o 7 0 2 0 - 9 0 0 - M a r i n g a´ - a n d e r s o n m a r c o l i n o @ g m a i l . c o m , p u t a c¸ a˜ o ( P C C ) d a U n i v e r s i d a d e E M ). m b o , 5 7 9 0 - Z o n a 0 7 P R -B ra s il e d s o n @ d i n . u e m . b r R e s u m o . A a b o rd a g e m d e L in h a d e P ro d u to d e S o ftw a re (L P S ) v e m s e n d o c o n s o l i d a d a n o s u ´ l t i m o s a n o s c o m o u m a f o r m a e f e t i v a d e r e u t i l i z a c¸ a ˜ o d e a r t e f a t o s d e s o ftw a re c o m b a s e e m v a r ia b ilid a d e s . S te re o ty p e -b a s e d M a n a g e m e n t o f V a r i a b i l i t y ( S M a r t y ) e´ u m a a b o r d a g e m p a r a g e r e n c i a m e n t o d e v a r i a b i l i d a d e s e m L P S b a s e a d a e m U M L . S M a r t y v e m s e n d o r e f e r e n c i a d a e m v a´ r i o s p r o j e t o s n o s u ´ l t i m o s a n o s . E n t r e t a n t o h a ´ a c a r eˆ n c i a d e s u a v a l i d a c¸ a ˜ o e x p e r i m e n t a l , b e m c o m o d e o u t r a s a b o r d a g e n s e x i s t e n t e s , a n t e s d e s u a p o s s ´ı v e l t r a n s f e r e ˆ n c i a p a r a a i n d u´ s t r i a . L o g o , p a r a q u e S M a r t y p o s s a t r a n s f e r i d a a` i n d u´ s t r i a , b e m c o m o t e r s e u u s o a m p l i a d o e m e s t u d o s a c a d eˆ m i c o s , u m a v e z q u e p o d e s e r a p l i c a d a e m p r o j e t o s e e s t u d o s o n d e a r e p r e s e n t a c¸ a ˜ o d e a r q u i t e t u r a s e a t i v o s d e L P S s n e c e s s i t e s e r f e i t a d e f o r m a s i m p l i fi c a d a , f a ´ c i l e e m c u r t o p r a z o ; u m c o n j u n t o d e e x p e r i m e n t o s e p o s s ´ı v e i s r e p l i c a c ¸ o ˜ e s s e r a ˜ o p l a n e j a d a s e c o n d u z i d a s p a r a S M a r t y e m s e u s v a ´ r i o s n ´ı v e i s d e a b s t r a c ¸ a ˜ o . A v a l i d a c ¸ a ˜ o e x p e r i m e n t a l d e S M a r t y c o n t r i b u i r a ´ c o m e v i d eˆ n c i a s d e s u a e f e t i v i d a d e , b e m c o m o s u a e v o l u c¸ a ˜ o , p e r m i t i n d o a s s i m s u a a d o c¸ a ˜ o . P a la v r a s -c h a v e : L in h a d e P ro d u to d e S o ftw a re , G e re n c ia m e n to d e V a r ia b ilid a d e s , S M a r t y , V a l i d a c¸ a ˜ o E x p e r i m e n t a l , U M L , M e t a m o d e l a g e m . 1 . C a r a c t e r i z a c¸ a ˜ o d o P r o b l e m a O g e r e n c i a m e n t o d e v a r i a b i l i d a d e s ( G V ) e´ u m a d a s a t i v i d a d e s e s s e n c i a i s d o c i c l o d e v i d a d e L in h a d e P r o d u to d e S o f tw a r e ( L P S ) [ L in d e n e t a l. 2 0 0 7 ] . O o b je tiv o d e ta l a tiv id a d e e ´ p e r m i t i r a i d e n t i fi c a c ¸ a ˜ o , a r e p r e s e n t a c ¸ a ˜ o e o r a s t r e a m e n t o d e v a r i a b i l i d a d e s d e u m a L P S . P a r a t a n t o , d i v e r s a s p r o p o s t a s v eˆ m s e n d o a p r e s e n t a d a s p e l a l i t e r a t u r a e x i s t e n t e [ C h e n e t a l . 2 0 0 9 ] . E n t r e t a i s a b o r d a g e n s a s q u e m a i s t eˆ m s i d o r e f e r e n c i a d a s s a˜ o a q u e l a s b a s e a d a s n a n o t a c ¸ a ˜ o U n i fi e d M o d e l i n g L a n g u a g e ( U M L ) c o m o , p o r e x e m p l o , o m e´ t o d o P L U S [ G o m a a 2 0 0 4 ] , S t e r e o t y p e - b a s e d M a n a g e m e n t o f V a r i a b i l i t y ( S M a r t y ) , [ O liv e ir a J u n io r e t a l. 2 0 1 0 , O liv e ir a J u n io r e t a l. 2 0 1 3 ] , e n tr e o u tr a s . A n [ a d a b o rd a g e m a s u a a d o c¸ a˜ o p o r F ra g a l e t a l. 2 0 1 3 ], e i n d u´ s t r i a , e u m a a m u z i r u m a s e´ r i e s d e e S M a r ty v e m s e d iv e r s o s p r o je to n tre o u tro s . A s s im p l i a c¸ a˜ o d e s e u u s x p e rim e n to s p a ra n d o c o n s o lid a d a s /tra b a lh o s , c o m o s u rg e a p o s s ib ilid o n a a c a d e m ia , lo g v e r i fi c a r s u a e f e t i v 118 n o s u´ l t i m o s a n o s , e m [C o n tie ri e t a a d e d e t r a n s f e r eˆ n c i a o h a´ a n e c e s s i d a d e id a d e e p e rm itir s u a c o l. 2 d e d e e v m b a 0 1 1 ] s ta p a se c o o l u c¸ a˜ se e ra n o , m e se n so s p ro e x p in d p ro so f d ia n te o s re s u lta d o s . U m c o n d o p la n e ja d a s e c o n d u z id a s d e u s o , c l a s s e e a e x t e n s a˜ o fi s s i o n a i s , p r o f e s s o r e s e e s t u e r u´ s c e tw A l e´ m im e n ta tria , s e sso s e a re , q u ju n to p a ra re c e n d a n te d o s m o tiv o s q u e ju s is p la n e ja d o s fu n d a m g u n d o [M a fra e t a l. 2 te c n o lo g ia s , g e ra n d o a n d o re la c io n a d o s a n t i fi e n 0 0 in o v e x S M te s d p e rim e n ta l, b e a r ty e m s e u s p a r a s e q u eˆ n c i a e e n g e n h a ria d c o m o p o s s ´ı v e i s r e p r i n c i p a i s n ´ı v e i s d e ), c o n ta n d o c o m a p e s o f t w a r e d e v a´ r i a s m c a m a v a l i d a c¸ a˜ o d e S M t a - s e n a i m p o r t aˆ n c i a d a 6 ], a in d a a p re s e n ta im a c e rte z a s e fa lta d e c re d a s p r o p o s t a s e a` a d o c¸ a˜ o p l i c a c¸ a b s tra a rtic ip in s titu o ˜ e s v eˆ m c¸ a˜ o ( c a a c¸ a˜ o d e i c¸ o ˜ e s . a r t y , a e x e c u c¸ a˜ o d o s e s t u d o a tiv id a d e d e G V , v is to q u e t u r i d a d e q u a n t o a` e s c o l h a d ib ilid a d e n o s e n g e n h e iro s d d e te c n o lo g ia s e m e rg e n te s . s a e e 2 . F u n d a m e n t a c¸ a ˜ o T e o ´ r i c a O su c e s tiv o G V [L in d e n d a s p a ra so q u e a . P o r e´ m , e t a l. 2 0 0 7 a i n d u´ s t r i a A a b o rd a g e m a b o rd a g e n s , C h e n e t a l. [S h u ll e t a l. a b o rd a g e m a s v a ria b ilid a d e s d e u [ O liv e ir a J u n io r e t a l. U M L 2 .0 , o S M a r ty P S te re m a L 2 0 1 3 r o fi l e o ty p e P S p o , O liv , e u m d e d e 2 0 2 0 L P S G V 0 9 ] p a 0 4 ], b -b a s ssa m e ira p ro v e m a l c a n c¸ a n d e x is te n te s c a re c ra q u e s e to rn e m e m c o m o a d o ta d e d M a n a g e m e n t o f s e r g e re n c ia d a s d e J u n io r e t a l. 2 0 1 0 ]. c e s s o , o S M a r ty P ro o se d e v e m d e v e f e tiv a s a s e m m a e c la ra m a l i d a c¸ a˜ o e p o ssa m is e s tu d o e n te a o e fe e x p e rim e n ta l s e r tra n s fe ris a c a d eˆ m i c o s . V a r ia b ility (S M a r ty ) p e rm ite q u e f o r m a e f e tiv a e m m o d e lo s U M L S M a r t y e ´ c o m p o s t a p o r u m p e r fi l c e ss. m ite c e sso a m e n fo rn e p rin c S M a r t y P r o fi l e , p o r m e i o d e u m c o n j u n t o d e e s t e r e o ´ t i p o s e m e t a - a t r i b u t o s r e p r e s e n t a r v a r i a b i l i d a d e s e m m o d e l o s U M L d e L P S . J a´ o S M a r t y P r o c e s s e´ u m s i s t e m a ´ t i c o q u e g u i a o u s u a ´ r i o n a i d e n t i fi c a c ¸ a ˜ o , d e l i m i t a c ¸ a ˜ o , r e p r e s e n t a c ¸ a ˜ o , r a t o d e v a r i a b i l i d a d e s e a n a ´ l i s e d e c o n fi g u r a c ¸ o ˜ e s d e p r o d u t o s d e u m a L P S . O p r o c c e u m c o n j u n t o d e d i r e t r i z e s q u e g u i a m o u s u a´ r i o n a r e a l i z a c¸ a˜ o d a s s u a s a t i v i d i p a i s , b e m c o m o n a a p l i c a c ¸ a ˜ o d o S M a r t y P r o fi l e . c o m p s is te m z a v a m a s s im E m s u a s p rim e ira s o n e n te s e a tiv id a d e s . a´ t i c a d a l i t e r a t u r a , u m o s d ia g ra m a s d e s e q u m a n o v a e x t e n s a˜ o p O A j u s t i fi c a t i v a p r i n c i p a l m e n t e , a` n e c e t a i s . J a´ a e x t e n s a˜ o d o re n c ia l d o s p a c o te s e o b ilid a d e s n e s te s e p ro p v e r s o˜ e s S M a r t y s u N e s te tra b a lh o d e d p e q u e n o n u´ m e r o u eˆ n c i a e d e p a c o t e a ra S M a r ty fo i p ro p a r a a e x t e n s a˜ o s s id a d e d e re p re m e c a n is m o d e p s s e u s d iv e r s o s c ic ia n d o a s s im , u p o rta v is s e rta d e a b o s (m e c p o s ta , d e S M a r s e n ta r a s a c k a g e m o m p o n e n m a v i s a˜ o a m c¸ a˜ o rd a g a n is a b ra o d e lo s d e c a s o s v e r i fi c o u - s e , p o r e n s b a se a d a s e m m o d e p a c k a g e m n g e n d o ta is m o d ty p a ra d ia g ra m v a ria b ilid a d e s e e rg e , o c o rre p o te s q u e s e m e s c m a c ro d o s is te m a s m r p la m a . d e s te rm e rm , e s p e rp ro s tre e sso a d e s d e u so m e io d U M L e rg e ) e lo s . , c la s s e s , e r e v i s a˜ o q u e u tilid a U M L , eˆ n c i a c o m p u m a i fi c a n se d e v e o rta m e n v i s a˜ o g e d o v a ria e q u o s itir p e c , - 3 . C o n t r i b u i c¸ o ˜ e s A s p r i n c i p a i s c o n t r i b u i c¸ o ˜ e s d o t r a b a l h o r e f e r e m - s e a v a l i d a c¸ a˜ o e x p e r i m e n t a l d a a b o r d a g e m S M a r t y p a r a m o d e l o s d e c a s o s d e u s o , c l a s s e s e s e q u eˆ n c i a e s u a e v o l u c¸ a˜ o m e d i a n t e o s re s u lta d o s o b tid o s n o s e x p e rim e n to s . O s re S M a r ty n a id e s u p o rta , b e m d e m e lh o ria s s u lta d o s n t i fi c a c ¸ a ˜ o c o m o a e e m p o s s ´ı v e x p e rim e re p re v o l u c¸ a˜ o e is p o n e n ta is s e n t a c¸ a˜ d e s ta , t o s n a˜ o p o o d m e tra s s i b i l i t a r a˜ o e v a ria b ilid d ia n te re s u ta d o s , o u tr 119 a a d lta a ta id e e s n d o s d o s n t i fi o s tr q u e d e f c a c¸ a˜ o d a e f e t i v i d a d e d e eˆ s p r i n c i p a i s m o d e l o s q u e e x p re s s e m a n e c e s s id a d e o rm a p a rc ia l. E n t e n d e - s e c o m o e f e t i v i d a d e , p a r a e s t e e s t u d o , a c a p a c i d a d e d e i d e n t i fi c a r e r e p r e s e n t a r a s v a r i a b i l i d a d e s c o r r e t a m e n t e , p o r m e i o d a a p l i c a c¸ a˜ o d e S M a r t y . a p u o s D e s ta m a n e ira , e s te e s tu d o v is s u a p o s s ´ı v e l a d o c ¸ a ˜ o p e l a i n d u ´ s t r i a , e e s q u is a s n a a c a d e m ia , p o is s u a fo rm m d o s a tr a tiv o s d e s e u u s o , p o is s e n d e a r e p r e s e n t a c¸ a˜ o d e a r q u i t e t u r a s e i m p l i fi c a d a , f a ´ c i l e e m c u r t o p r a z o . a a v a lia t a m b e´ m a d i n aˆ m to rn a fa a tiv o s d r a e f e tiv id a d e d e S M p e r m i t i r a a m p l i a c¸ a˜ i c a d e a p l i c a c¸ a˜ o , a v a c ilm e n te a p lic a d a e m e L P S s n e c e s s ite m s e a r ty o d e lia d a p ro re m p a ra p ro p ic ia s u a a d e s a˜ o e m a q u i, s e to rn je to s e e s tu d o fe ita s d e fo rm r a s a A i n d a , c o m o c o n t r i b u i c¸ a˜ o i n d i r e t a d e s t e t r a b a l h o , a s b o a s p r a´ t i c a s d e e x p e r i m e n t a c¸ a˜ o p e s q u i s a d a s e u t i l i z a d a s s e r a˜ o d i s p o n i b i l i z a d a s p a r a a a c a d e m i a , p e r m i t i n d o s u a a p l i c a c ¸ a ˜ o e m p o s s ´ı v e i s a v a l i a c ¸ o ˜ e s d e o u t r a s a b o r d a g e n s d e G V b a s e a d a s e m U M L . 4 . E s ta d o A tu a l d o T r a b a lh o E s t e t r a b a l h o e´ c o m p o s t o p o r d i v e r s o s e s t u d o s e x p e r i m e n t a i s , e s t e s e s t u d o s e s t a˜ o p r o g r a m a d o s c o n fo rm e o c ro n o g ra m a d a T a b e la 1 . D o is d o s e s tu d o s , p a ra c a s o s d e u s o e c la s s e s j a´ f o r a m r e a l i z a d o s e s a˜ o b r e v e m e n t e d e s c r i t o s a s e g u i r : T a b e l a 1 . V a r i ´a v e i s a s e r e m c o n s i d e r a d a s n a a v a l i a c ¸ ˜a o d a s t ´e c n i c a s d e i n t e r a c ¸ ˜a o P p d d d e m p n E s tu d o E x p e r im a p l i c a c¸ a˜ o d a a b o r d a g e m c o m o m e´ t o d o P L U S . F o p a n te s m o d e la ra m a L P S e o m e´ t o d o P L U S [ G o m S M a r t y e m r e l a c¸ a˜ o a o P [M a rc o lin o e t a l. 2 0 1 3 ]. a e n ta l p a r a M o d e lo d e C a s o s d e U s o - V a lid a r a S M a r ty p a ra m o d e lo s d e c a s o s d e u s o d a U M L , e i re a liz a d o e m S e te m b ro d e 2 0 1 2 , n o q u a l d o is g ru e -c o m m e rc e [G o m a a 2 0 0 4 ] d e a c o rd o c o m a a b o r a a 2 0 0 4 ] . E s t e e s t u d o a p r e s e n t o u e v i d eˆ n c i a s d a L U S e o a rtig o g e ra d o a p a rtir d e le fo i a c e ito p e f e tiv id a d e d e c o m p a r a c¸ a˜ o p o s d e p a rtic id a g e m S M a r ty e f e tiv id a d e d e a r a p u b l i c a c¸ a˜ o m E s t u d o E x p e r im e n t a l p a r a M o d e lo d e C la s s e s - V a lid a r a e f e tiv id a d e d e p l i c a c¸ a˜ o d e S M a r t y p a r a m o d e l o s d e c l a s s e s d a U M L , e m c o m p a r a c¸ a˜ o c o m a a b o r d a g e m L U S . C o n d u z id o e m A b ril d e 2 0 1 3 , n o q u a l d o is g ru p o s d e p a rtic ip a n te s , b a la n c e a d o s o r n ´ı v e l d e c o n h e c i m e n t o , m o d e l a r a m d u a s L P S s ( e - c o m m e r c e e A r c a d e G a m e M a k e r ) e a c o r d o c o m a a b o r d a g e m S M a r t y e o m e´ t o d o P L U S . E s t e e s t u d o a p r e s e n t o u e v i d eˆ n c i a s a e f e t i v i d a d e d e P L U S e m r e l a c¸ a˜ o a S M a r t y , l e v a n d o a e v o l u c¸ a˜ o d e s t e u ´ l t i m o . O a r t i g o e s t e e s t u d o e s t a´ s e n d o p r e p a r a d o . E´ i m p o r t a n t e o b s e r v a r , q u e a c a d a n o v o e x p e r i m e n t o , o f e e d b a c k d o s p a r t i c i p a n t e s a a n a ´ l i s e d o s r e s u l t a d o s , t a n t o e m r e l a c ¸ a ˜ o a o s t e s t e s e s t a t ´ı s t i c o s u t i l i z a d o s , c o m o n a e t o d o l o g i a d e a p l i c a c¸ a˜ o d o s e x p e r i m e n t o s ; p e r m i t e m a l a p i d a c¸ a˜ o e m p r o l d a m e l h o r i a d o r o ´ x i m o a s e r c o n d u z i d o , p r e z a n d o p e l o a p r i m o r a m e n t o n o p r o c e s s o d e e x p e r i m e n t a c¸ a˜ o o q u e ta n g e G V e m m o d e lo s U M L . 120 5 . C o m p a r a c¸ a ˜ o c o m N o ta -s e n b a se a d a s s id e ra d a s v a l i d a c¸ o ˜ e a lite ra e m U M p o r [C s e x p e r tu ra e x L o u h e n e t im e n ta O s a u to re s d e v a l i d a c¸ a˜ o d a s m d o s , a q u a n tid a d e e x i s t e n t e s , e´ m u i t o q u e fa to rim c o m a p e s d e in T r a b a lh o s R e la c io n a d o s i s t e n t e , q u e d i v e r s a s s a˜ o a s p r o p o s t a s d e a b o r d a g e n s d e G V , s e j a m n a˜ o , t a i s c o m o a d e [ G o m a a 2 0 0 4 ] e [ Z i a d i e t a l . 2 0 0 3 ] e a s c o n a l . 2 0 0 9 ] , e n t r e o u t r a s . E n t r e t a n t o , d e p a r a m o s c o m a a u s eˆ n c i a d e is . r e s e n t a m u m p e q u e n o e x e m p l o d e a p l i c a c¸ a˜ o , i n d i c a a n e c e s s i d a d e m a s , m a s , a o p e s q u is a r-s e n o s m e c a n is m o s d e b u s c a m a is c o n h e c iv a l i d a c¸ o ˜ e s e x p e r i m e n t a i s , s e c o m p a r a d o a o n u ´ m e r o d e a b o r d a g e n s fe rio r. A i n e x i s t eˆ n c i a d e te m e m e rg id o c o m o r q u e m o tiv a o d e s e n v e n ta is m a is d ifu n d id o u n id a d e . t a i s v a l i d a c¸ o ˜ e s e u m a p ro m is s o ra o lv im e n to d e s te s n a lite ra tu ra , a x p e rim e n ta is , p rin c ip a lm a b o rd a g e m p a ra o re u so e s tu d o , q u e c o n s o lid a d o g r e g a r a ´ a v a n c ¸ o s s i g n i fi c a e n [L c o t iv te in m o s p a ra d e n o s m p a r G V e m L P S e t a l. 2 0 0 7 ] o d e lo s e x p e a a r e s p e c tiv , e´ a 6 . A v a l i a c¸ a ˜ o d o s R e s u l t a d o s O s r e s u l t a d o s o b t i d o s n o p r i m e i r o e s t u d o c o n c l u ´ı d o [ M a r c o l i n o e t a l . 2 0 1 3 ] p a r a m o d e l o s d e c a s o s d e u s o p o s s i b i l i t a r a m a f o r m u l a c¸ a˜ o d e n o v o s m e´ t o d o s p a r a a a p l i c a c¸ a˜ o d o s e g u n d o e x p e rim e n to (m o d e lo s d e c la s s e s ). A s p r in c ip a is a tiv id a d e s c o n d u z id a s n o p r o c e s s o e x p e r im e n ta l d e c a s o s d e u s o e c l a s s e s s a˜ o r e s u m i d a s F i g u r a 1 . F ig u r a 1 . E ta p a s d o E x p e r im e n to p a r a M o d e lo s d e C a s o s d e U s o e C la s s e s . A s a tiv id a d e s r e a liz a d a s a o lo n g o d o s p r im e ir o s e s tu d o s ( F ig u r a 1 ) c r ia m u m a b a s e p a r a a c o n d u c¸ a˜ o d o s d e m a i s , e e s t a s s e r a˜ o d i f u n d i d a s p a r a a a c a d e m i a , p e r m i t i n d o a a v a l i a c¸ a˜ o d e o u t r a s a b o r d a g e n s d e G V b a s e a d a s e m U M L . O s r e s u l t a d o s o b t i d o s a t e´ o m o m e n t o e a p r e s e n t a d o s a n t e r i o r m e n t e ( S e c¸ a˜ o 4 ) , f o r n e c e m e v i d eˆ n c i a s d a e f e t i v i d a d e d e S M a r t y p a r a c a s o s d e u s o , e a n e c e s s i d a d e d e e v o l u c¸ a˜ o d a m e s m a p a r a c l a s s e s . L o g o , r e p l i c a c¸ o ˜ e s p a r a e s t e s e s t u d o s o r i g i n a i s s a˜ o n e c e s s a´ r i a s , 121 c o m o j u s t i fi c a d a s e m [ M e n d o n c a e t a l . 2 0 0 8 ] e e m o u t r o s e s t u d o s , p o i s g a r a n t e m m a i o r e s e v i d eˆ n c i a s d o s r e s u l t a d o s o b t i d o s , a l e´ m d e p e r m i t i r a a v a l i a c¸ a˜ o d a s m u d a n c¸ a s a p l i c a d a s a S M a r t y , a p o ´ s a n a´ l i s e d o s r e s u l t a d o s , p a r a o s e x p e r i m e n t o s j a´ e x e c u t a d o s . R e f e r eˆ n c i a s C h e n , L ., A li B a b a r, M ., a n d A li, N . ( 2 0 0 9 ) . V a r ia b ility M a n a g e m e n t in S o f tw a r e P r o d u c t L in e s : a S y s te m a tic R e v ie w . In P ro c e e d in g s o f th e In te r n a tio n a l S o ftw a re P ro d u c t L in e C o n fe re n c e , p a g e s 8 1 – 9 0 , P itts b u rg h , P A , U S A . C o n tie r i, J r., E . A ., F e r r to d e v e lo p E u ro p e a n S p rin g e r-V F ra g a l, V . H p lic a tio n S im u lin k re n c e o n A . C a ri, S s o ftw c o n fe e rla g ., C o r r e ., M a s ie a re p ro re n c e o . ., S ilv a , E n g in e e r w ith in a E n te r p r is R in P e ia , ro , d u c n S . F ., g fo ro d u In fo G . G P . C t-lin o ftw ., C ., a n e a r a re O liv e ir a r E m b e d d c t-lin e b a r m a tio n S o la n d G a c h ite a rc h z i, T . E ., rc ia , A . F . c tu re s : le s ite c tu re , p G im (2 0 so n a g e e n e 1 1 ). s le a s 1 3 s, I. M E x te n rn e d . 0 – 1 3 8 J u n io r, E . A ., a n d e d S y s te m s : T ra n s se d A p p ro a c h . P ro y s te m s , A n g e rs . (a c G im fo rm c e e d e ito e n e s in g in g s p a ra . S ., O liv e ir a J u n io r, d in g u m l c o m p o n e n ts In P ro c e e d in g s o f th e , B e rlin , H e id e lb e rg . , I. M . S y sM L o f In te r p u b lic a G o m a a , H . (2 0 0 4 ). D e s ig n in g S o ftw a re P ro d u c t L in e s w ith U M L : F ro m P a tte r n -B a s e d S o ftw a re A rc h ite c tu re s . A d d is o n W e s le y . S . S p n a c¸ a˜ (2 0 1 3 ). A p e c i fi c a t i o n t o tio n a l C o n fe o ). U s e C a s e s to L in d e n , F . J ., S c h m id , K ., a n d R o m m e s , E . ( 2 0 0 7 ) . S o ftw a r e P r o d u c t L in e s in A c tio n : T h e B e s t In d u s tr ia l P r a c tic e in P ro d u c t L in e E n g in e e r in g . S p rin g e r, B e rlin . M a f r a , S . N ., B a r c e lo s , R . F ., a n d T r a v a s s o s , G . H . ( 2 0 0 6 ) . A p lic a n d o u m a M e to d o lo g i a B a s e a d a e m E v i d e ˆ n c i a n a D e fi n i c ¸ a ˜ o d e N o v a s T e c n o l o g i a s d e S o f t w a r e . I n X X S i m p o´ s i o B r a s i l e i r o d e E n g e n h a r i a d e S o f t w a r e , p a g e s 2 3 9 – 2 5 4 , F l o r i a n o´ p o l i s , S C . M a r T P g c o o w ro in lin o , a rd s c e e d e e r in M e n d o n c a , G . H ., H rim e n ta l 2 0 0 8 . 1 3 A ., th e in g s g , (a M o h R th O liv e E ffe c o f In c e ito ira tiv te r p a ., M a ld o n , E ., a n e p lic a tio IE E E In J u n io e n e ss n a tio n ra p u b n a d d B n s. te r n r, E o f a a l C lic a o , J ., a s ili, In E n a tio n . A V a o n c¸ a˜ o d e O V . (2 g in e a l C ., G im e n e s , I . M . S ., a n d M a ld o n a d o , J . C . ( 2 0 1 3 ) . ria b ility M a n a g e m e n t A p p ro a c h a t U s e C a s e L e v e l. fe re n c e o n S o ftw a re E n g in e e r in g & K n o w le d g e E n ). liv e ir a 0 0 8 ). e r in g o n fe re , M A o f n c ., C a r v F ra m e w C o m p le e o n , p a e r, J ., F a b b r i, S ., S h u ll, F ., T r a v a s s o s , o rk fo r S o ftw a re E n g in e e rin g E x p e x C o m p u te r S y s te m s , 2 0 0 8 . IC E C C S g e s 2 0 3 – 2 1 2 . O liv e ir a J u n io r, E . A ., G im e n e s , I . M . S ., a n d M a ld o n a d o , J . C . ( 2 0 1 0 ) . S y s te m a tic M a n a g e m e n t o f V a ria b ility in U M L -b a s e d S o ftw a re P ro d u c t L in e s . J o u r n a l o f U n iv e r s a l C o m p u te r S c ie n c e , 1 6 (1 7 ):2 3 7 4 – 2 3 9 3 . O liv e ir a J u n io r, E . A ., G im e n e s , I . M . S ., a n d M a ld o n a d o , J . C . ( 2 0 1 3 ) . S y s te m a tic E v a lu a tio n o f S o ftw a re P ro d u c t L in e A rc h ite c tu re s . J o u r n a l o f U n iv e r s a l C o m p u te r S c ie n c e , 1 9 (1 ):2 5 – 5 2 . S h u l l , F . , M e n d o n c c¸ a , M . G . , B a s i l i , V . , C a r v e r , J . , M a l d o n a d o , J . C . , F a b b r i , S . , T r a v a s s o s , G . H ., a n d F e r r e ir a , M . C . ( 2 0 0 4 ) . K n o w le d g e - s h a r in g is s u e s in e x p e r im e n ta l s o f tw a r e e n g in e e r in g . E m p ir ic a l S o ftw . E n g g ., 9 ( 1 - 2 ) :1 1 1 – 1 3 7 . Z i a d i , T . , H e l o u e t , L . , a n d J e z e q u e l , J . M . ( 2 0 0 3 ) . T o w a r d s a U M L P r o fi l e f o r S o f t w a r e P ro d u c t L in e s . In In S o ftw a re P ro d u c t-F a m ily E n g in e e r in g , p a g e s 1 2 9 – 1 3 9 . S p rin g e r. 122 XDTv: um método Ágil para o Desenvolvimento de Aplicações para TV Digital Mario Godoy Neto1, 2, Carlos André Guimarães Ferraz2 1 Universidade Federal do Vale do São Francisco (UNIVASF) Av. Antônio Carlos Magalhães, 510, Country Club - 48.902-300 - Juazeiro - BA - Brasil 2 Centro de Informática – Universidade Federal de Pernambuco (CIn / UFPE) Caixa Postal 7851, Cidade Universitária - 50.732-970 - Recife - PE - Brasil [email protected], [email protected] Abstract. Nowadays more and more computing devices arise with different applicabilities. Software applications peculiarities for Digital TV (DTV), for example, require special attention in its development process, such as multimedia content gathering requirements (size, display time, location and timing) and development time (limited by the production time of the TV program). This thesis presents an agile and hybrid development method, instantiated for DTV environment and named eXtreme Digital Television (XDTv). The goal is to contribute with the handling of such peculiarities. Experimental results provide outcomes that XDTv contributes to improve the performance of software applications development for DTV. 1. Introdução A TV Digital (TVD) oferece, além do áudio e do vídeo de alta definição, uma nova plataforma computacional capaz de executar aplicações interativas. O padrão de TVD, adotado para a realização dos experimentos nesta pesquisa, é o Nipo-Brasiliero Integrated Services Digital Broadcasting-Terrestrial Brazil (ISDB-Tb) [Soares et al., 2010], que utiliza o middleware Ginga, reconhecido como padrão International Telecommunication Union (ITU) para serviços de IPTV (ITU-T H.761), aumentando sua aplicabilidade. Contudo, as contribuições desta pesquisa não se restringem ao ISDB- Tb. Independente do middleware adotado, as aplicações para TVD apresentam peculiaridades que demandam atenção especial em seu processo de desenvolvimento [Lula, et al., 2011], [Marques Neto, 2011]. Diferentes tipos de software exigem abordagens diferentes, pois não existem métodos de desenvolvimento universais [Sommerville, 2011]. O relatório [CHAOS, 2010] revelou que, projetos Ágeis foram melhores que os projetos Cascata, apresentando: a) 3% menos fracassos;; b) 14% menos modificações no orçamento ou funcionalidades;; c) 17% mais sucessos. Dentre os métodos Ágeis, aqueles mais utilizados são Scrum e XP. No entanto, estes ainda não preveem as peculiaridades das aplicações de TVD, demandando por adaptações [Veiga, 2006], [Marques Neto, 2011]. Para a presente pesquisa, um método adequado ao desenvolvimento de aplicações para TVD deve auxiliar as atividades de Planejamento, Especificação, Desenvolvimento e Testes. O desenvolvimento de software tradicional se difere do desenvolvimento de TVD devido às peculiaridades de suas aplicações, tais como: a) Ação coadjuvante – a aplicação não é o foco dos usuários, esta deve agregar valor ao 123 conteúdo audiovisual;; b) Curto ciclo de vida – a aplicação é sincronizada com o audiovisual, que pode durar poucos minutos e ser veiculado durante poucos dias [Lula, et al., 2011];; c) Contexto do usuário – vários para a mesma plataforma;; ambiente informal;; meio de interação limitado;; d) Broadcast – enviada unilateralmente para todos os usuários;; e) Impacto instantâneo – uma cidade, região ou o país recebem simultaneamente;; f) Objetos multimídia – arquivos de texto, código Lua, imagens, áudio e vídeo formam um fluxo, necessitando coletar seus requisitos: dimensão, início, duração, pilha, ordem, etc.;; g) Rapidez no desenvolvimento – devem acompanhar a rápida produção do audiovisual: telejornais, notícias de última hora, entre outros [Veiga, 2006], [Lula, et al., 2011];; h) Agilidade – adaptação às mudanças de requisitos;; i) Equipe multidisciplinar – diretores de arte e de áudio, roteiristas, desenvolvedores de software e outros, devem se comunicar claramente [Veiga, 2006], [Lula, et al., 2011]. Os objetivos específicos da presente pesquisa são: 1) investigar a adequação dos métodos ágeis no desenvolvimento de aplicações para TVD;; 2) apresentar o método de desenvolvimento híbrido e ágil, denominado eXtreme Digital Television (XDTv), cujo objetivo é auxiliar no trato das peculiaridades de tais aplicações. As principais contribuições são: a) levantamento das peculiaridades das aplicações, pontos de melhoria e métricas sobre a adoção dos métodos Scrum, XP, Híbrido (Scrum/XP) e XDTv;; b) o método XDTv e seus artefatos. As técnicas de pesquisa adotadas foram: bibliográfica, exploratória, qualitativa, quantitativa e experimental [Marconi e Lakatos, 2003]. As variáveis de controle dos experimentos foram operacionalizadas através de orientação, supervisão e padronização dos materiais e métodos. Os experimentos foram baseados em [Travassos, 2002], os times de desenvolvimento formados por alunos da disciplina Tópicos Avançados em Engenharia de Software do 10º período de Engenharia da Computação (UNIVASF). Foram adotadas as seguintes técnicas de coleta de dados: questionário objetivo (escala de Likert), questionário descritivo, sintetizado através de palavras-chaves, seguido pela entrevista semiestruturada em grupo e individual. Tais formulários estão disponíveis em: http://www.univasf.edu.br/~mario.godoy/xdtv. As limitações dessa pesquisa são: a) os experimentos controlados podem não refletir a indústria;; b) as conclusões são restritas aos métodos investigados;; c) o método XDTv precisa ser avaliado por profissionais;; d) a qualidade das aplicações desenvolvidas não foi considerada. Os riscos à validade dos experimentos são: a) apesar dos requisitos não funcionais diferentes e a inspeção do código não apresentar evidência de seu compartilhamento, há uma pequena possibilidade do seu compartilhamento parcial;; b) apesar do balanceamento dos times através de entrevista e análise de currículo, é possível que exista algum membro com maior afinidade e/ou dedicação. 2. Trabalhos Relacionados Lula (2011) apresenta um processo ágil para especificação de requisitos com foco na integração dos roteiros literários e técnicos da TV com as aplicações, utilizando exclusivamente descrições textuais para a especificação e criação das histórias e os storyboards. Suas conclusões destacam que a descrição textual não é a melhor forma de coletar tais requisitos, e que a equipe de software deve se adequar às mudanças de requisitos de forma rápida e adequada aos profissionais de TV. No entanto, a proposta do autor é voltada para integração de diferentes profissionais, não apresenta uma adequação voltada para o desenvolvimento das aplicações e suas peculiaridades. 124 A tese [Marques Neto, 2011] apresenta o StoryToCode voltado à concepção de componentes interativos e reuso de código para diferentes plataformas (TVD, Mobile, Web, etc), utilizando storyboards como fonte de obtenção de requisitos. Entre suas limitações está a extração de requisitos de forma não automatizada e o retrabalho necessário para completar o código. Segundo o autor, a literatura especializada não apresenta uma solução formal para a coleta de requisitos multimídia, reuso e modelos de processos de desenvolvimento, principais problemas do desenvolvimento de aplicações para TVD. Destaca ainda a dificuldade em realizar testes no contexto de TVD. No entanto, afirma que os métodos ágeis são candidatos em potencial para essa plataforma. Diferente da presente pesquisa, os trabalhos relacionados não apresentam um método de desenvolvimento de aplicações de TVD e não especificam um meio para coleta de requisitos multimídia, o que pode acarretar no aumento do tempo de desenvolvimento [Marques Neto, 2011]. A presente pesquisa apresenta os detalhes dos experimentos realizados, permitindo sua replicação. O método proposto (XDTv) não utiliza dados textuais na coleta de requisitos, seus artefatos exclusivos visam atender as peculiaridades das aplicações de TVD, em especial, a coleta de requisitos multimídia. 3. Experimento 1: Investigação de Métodos Ágeis O Experimento 1 avaliou os métodos Scrum, XP e híbrido (Scrum/XP). As variáveis dependentes foram: Adequação e Tempo referente ao Planejamento e Implementação. As questões de pesquisa foram: Q1) Tais métodos satisfazem às peculiaridades das aplicações de TVD? Q2) Qual método torna a implementação mais rápida? Sobre a adequação dos métodos às peculiaridades das aplicações, foram definidas as seguintes Hipóteses Nulas: H0 - os métodos são igualmente adequados;; H1 - o tempo de desenvolvimento é equivalente. Como Hipóteses Alternativas são: H2 - os métodos podem ser aprimorados;; H3 - o método Scrum é o mais adequado;; H4 - o método XP é o mais adequado;; H5 - o método híbrido é o mais adequado. As variáveis independentes foram: a) Três membros por time. Distribuição balanceada por análise de currículo;; b) Inexperientes sobre TVD. Dedicadas 30 horas de treinamento;; c) Métodos investigados: Scrum;; XP;; híbrido (Scrum/XP);; d) Método adotado através de sorteio;; e) Aplicação e requisitos idênticos;; f) Prazo de entrega: 3 semanas;; g) Cliente: o autor da presente pesquisa;; h) Reuniões com o cliente: 6 de 30 minutos;; i) Três iterações;; j) Ferramentas: Eclipse;; Plugins: RSE, Lua, NCL;; VMware;; Ginga Fedora. Resumidamente, a aplicação desenvolvida correspondia a uma arquibancada virtual de futebol, oferecendo informações adicionais sobre o campeonato e as várias equipes, ranking, visualização do jogo por até quatro ângulos diferentes, resize, pausa e retomada do vídeo, publicidade e vendas de produtos. Os três times implementaram todas as funcionalidades solicitadas. As horas dedicadas às reuniões são: Scrum = 16:00;; XP = 15:30;; Híbrido = 17:30 horas. As horas referentes a implementação são: Scrum = 59:00;; XP = 46:09;; Híbrido = 38:29 horas. Os métodos (XP e Híbrido) reduziram, em média, 21% (17 horas) da carga horária para finalizar os projetos. As perguntas objetivas são: P1) o grau de desgaste do desenvolvedor;; P2) o quão a metodologia auxiliou;; P3) o grau de complexidade da aplicação;; P4) complexidade de codificar suas funcionalidades. As repostas variavam de 0 a 4. O resultado da pergunta P1 foi igual (3) para todos os times. As demais pontuações foram: a) time Scrum – P2 = 125 3;; P3 = 3;; P4 = 2;; b) time XP – P2 = 3;; P3 = 2;; P4 = 3;; c) time Híbrido – P2 = 2;; P3 = 2;; P4 = 2. As perguntas descritivas levantaram os seguintes pontos fortes: a) entrega rápida torna o feedback eficiente;; b) a alteração de requisitos não implica em refatoração;; c) programação em par e reuniões stand up são produtivas. Os pontos fracos são: a) reuniões síncronas;; b) integração de versões;; c) implementação cansativa. Todos os times julgaram os métodos adotados adequados mediante modificações. A entrevista individual constatou que há esforço repetitivo na codificação NCL e quanto maior for o código implementado, mais difícil torna-se sua compreensão. Visando um levantamento mais próximo do mercado real foi realizado um survey. Foram considerados válidos 17 participantes, com formação em Ciência da Computação e tempo médio de experiência com o desenvolvimento de aplicações para TVD de 2 anos e 8 meses, sendo: a) apenas profissional = 2;; b) apenas acadêmico = 6;; c) profissional e acadêmico = 9 participantes. O nível de instrução: a) Graduandos = 3;; b) Mestrandos = 3;; c) Especialista = 1;; d) Mestres = 2;; e) Doutorandos = 5;; f) Doutores = 3. A média da autoavaliação do conhecimento de TVD foi de 7,94, escala de: “0” (no conheo), at “10” (especialista). Os métodos adotados: não utilizam = 7 (41%);; Scrum customizado = 5;; Scrum puro = 2. Os demais foram citados uma vez: Iconix, CMM, MPS, CMMi, XP e Story to Code, todos customizados. Práticas de engenharia de software essenciais à TVD: a) Todas = 6;; b) Especificação = 8;; c) Testes =5;; d) Planejamento = 4;; e) Reuso = 2;; f) Prototipagem = 2. Sobre as práticas ágeis: a) 7 (41%) não adotam;; b) Scrum = 3;; c) Protótipos de baixa fidelidade = 2;; d) Reuso = 2;; e) Story to Code = 1;; f) TDD = 1;; g) Programação em par = 1. Documentações adotadas: a) documento de requisitos = 7;; b) não utilizam = 4;; c) protótipos de baixa fidelidade = 3;; d) UML =2;; e) os demais (plano de projetos, caso de uso, diagrama de classes, ferramentas de IHC, mapas conceituais, documento de testes) foram citados uma vez. A média da adequação do XP à TVD = 6, variância = 4 e desvio padrão = 2. O ponto de melhoria está na coleta de requisitos multimídia. A média da adequação do Scrum = 7,18, variância = 1,56 e desvio padrão = 1,25. As melhorias são nas: a) sprints;; b) documentação;; c) testes;; d) validação. A diferença entre as médias de XP e Scrum é de 1,18 pontos e do desvio padrão foi 0,75 pontos. Ambos os métodos estão pouco acima da média (5), indicando a necessidade de adaptações. A vasta gama de métodos e documentos utilizados indicam que há demanda por padronização. Tais resultados foram utilizados na especificação do método XDTv. 4. O Método XDTv O método eXtreme Digital Television (XDTv) pode ser classificado como um método Ágil, híbrido e customizado, pois agrega técnicas de diversos métodos e é adaptado às necessidades inerentes às peculiaridades das aplicações para TVD, pretendendo auxiliar no: a) planejamento, especificação e implementação;; b) requisitos multimídia e fluxo de mídias;; c) identificação de falhas;; d) alteração de requisitos. As atividades de Evolução e Validação estão fora do escopo, porém, são consideradas trabalhos futuros. O XDTv apresenta na Figura 1 dois novos artefatos. O modelo de Protótipo de Aplicações para TV (PATv) de baixo nível de fidelidade [Snyder, 2003], para a coleta dos requisitos de mídias, uma evolução do Storyboard, devido à sequência lógica baseada em eventos e à interação do usuário [Veiga, 2006], [Marques Neto, 2011]. O 126 Modelo de Fluxo e Sincronismo de Mídia (MFSM), é uma evolução da visão estrutural [Soares Neto, et al., 2007], auxilia na: comunicação, no levantamento de requisitos, gestão do fluxo de mídias, implementação e documentação, dificuldades encontradas no Experimento 1 e trabalhos relacionados [Marques Neto, 2011]. Figura 1. Artefatos PATv e MFSM O MFSM aprofunda a coleta de requisitos do modelo PATv e especifica as características de qualquer aplicação, realizando o mapeamento dos eventos (condição / ações). Os itens (a, b, c, d, e f, g e h) da Figura 1, representam os elementos de NCL. O exemplo corresponde a uma aplicação simples do tipo enquete. O Modelo de Processo e o Ciclo de Vida do XDTv são apresentado na Figura 2. Figura 2. Modelo de processo e ciclo de vida do método XDTv O modelo de processo (a) do método XDTv adota características do método iterativo e incremental, possibilitando: entrega rápida de software;; alteração de requisitos;; constante identificação de falhas. O ciclo de vida (b) se inicia na coleta de requisitos até a entrega do módulo funcional. Para isso, existem os papéis: Programadores (para todos), Scrum Master e Prototipador. O Scrum Master acumula a função do Tracker, original do XP. O programador acumula a função de testador. O Prototipador é responsável pela engenharia de requisitos, através dos artefatos PATv e MFSM. O XDTv adota: Product Backlog, Sprint Planning, Sprint Backlog, Sprint Daily, originais do Scrum, incorporadas às práticas: programação em par, padronização do código e constante integração de versões, originais do XP. 127 5. Experimento 2: A Avaliação do Método XDTv No Experimento 2 são investigados os métodos híbridos (Scrum/XP) e o XDTv, suas variáveis dependentes eram a Adequação e o Tempo. As questões de pesquisa eram: Q1) Qual melhor método para a coleta de requisitos, planejamento e implementação de aplicações para TVD? Q2) Qual método torna o desenvolvimento mais rápido? As Hipóteses Nulas eram: H0 - o tempo de desenvolvimento é igual;; H1 - a Especificação, Planejamento e Implementação são igualmente adequadas. As Hipóteses Alternativas apontam que XDTv é mais rápido: H2 – de forma geral;; H3 – no Planejamento;; H4 – na Especificação;; H5 – na Implementação;; H6 – XDTV é mais adequado em geral. As variáveis independentes foram: a) Desenvolvedores: 12 que não participação do Experimento 1;; b) Sorteio dos times: A, B, C e D;; c) Membros por time: 3;; d) Sorteio dos membros e aplicações;; e) Requisitos funcionais: idênticos;; f) Requisitos não funcionais diferentes;; g) Implementação em série;; h) Atividades realizadas em equipe;; i) Prazo de entrega de 3 semanas;; j) Cliente o autor;; k) Seis reuniões com o cliente, 30 minutos, total: 3h por time;; l) Três iterações;; m) Uma semana por iteração;; n) Ferramentas: Eclipse Helios;; Maquina virtual VMware;; Ginga Fedora;; ManicTime na coleta das horas de implementação;; o) Conteúdo multimídia disponibilizado previamente. A igualdade entre os times se deu através de dois Quadrados Latinos (2x2) [Sánchez, 2011], cada time desenvolveu integralmente duas aplicações com dificuldade similar. Resumidamente, a Aplicação A corresponde a uma concessionária de veículos, apresentando informações sobre suas marcas, modelos, agendamento de test drive. A Aplicação B corresponde a uma construtora, apresentando informações sobre seus edifícios, os vários apartamentos e o armazenamento de oferta de compra. São utilizados os recursos de âncora, resize, propriedades, botões coloridos, setas direcionais, comandos start, stop, abort, resume, Lua entre outros. A Figura 3 apresenta a soma do tempo dedicado ao Planejamento (P), Especificação (E) e Implementação (I). Figura 3. Experimento 2- horas de trabalho e questionário Ao fim de cada aplicação foi aplicado um questionário objetivo - escala: 1 (inadequado) até 5 (adequado). As médias obtidas pela Aplicação 1 são: Híbrido = 47 e XDTv = 47,5, esta pequena variação se deve a ausência de parâmetro de comparação. Ao fim da Aplicação 2: Híbrido=39 e XDTv=47 pontos em média, o método híbrido obteve uma nota 17% menor e o XDTv se manteve constante. A Figura 3 apresenta as respostas de 11 dos 12 desenvolvedores sobre o Questionário 3 (descritivo). O objetivo era encontrar o método que melhor contribuiu para: P1) Requisitos;; P2) Planejamento;; P3) Implementação;; P4) Artefatos mais adequados? P5) Em geral, qual método 128 contribuiu mais? P6) Qual método o participante adotaria? A adequação do método híbrido (Scrum/XP) variou entre 4 e 7, com média = 6,36. A pontuação do XDTv variou entre 8 e 10, com média = 9,18 – escala de 0 (inadequado) até 10 (totalmente adequado). 6. Conclusões e Trabalhos Futuros Visando auxiliar no desenvolvimento de aplicações para TVD, a presente pesquisa realizou o levantamento da literatura especializada, o primeiro experimento, seguido por um survey com profissionais, para definir a síntese das peculiaridades de tais aplicações. Baseado nos resultados obtidos foi especificado o método eXtreme Digital Television (XDTv) e seus artefatos PATv e MFSM, cujo objetivo é auxiliar o processo de desenvolvimento de aplicações para TVD com foco na velocidade das atividades Planejamento, Especificação e Implementação. O segundo experimento apontou que o método XDTv obteve melhor desempenho e adequação sobre todas variáveis dependentes, exceto na atividade de Planejamento. Os resultados obtidos permitiram avaliar as hipótese levantadas, refutando as Hipóteses Nulas H0 e H1 e a Hipótese Alternativa H3, indicando que o método XDTv apresenta contribuições promissoras. Para conclusão da presente pesquisa pretende-se apresentar melhorias para a atividade de Planejamento e realizar uma reavaliação do método XDTv e seus artefatos através de um novo survey com desenvolvedores experientes no desenvolvimento de aplicações para TVD. Referências Soares, L. F. G., Moreno, M. F., Soares Neto, C. S., Moreno, M. F. "Ginga-Ncl: declarative middleware for multimedia IPTV services". In: Communications Magazine, IEEE, 2010. Lula, M. M. M., Guimarães, A. P., Tavares, T. A., "Um processo ágil para especificação de requisitos em programas interativos com foco em roteiros de tv". In: SBQS, 2011. Marques Neto, M. C., "Contribuições para a modelagem de aplicações multimídia em TV digital interativa". Tese (Doutorado) UFBA, UEFS e UNIFACS, 2011. Sommerville, I. "Engenharia de software," Editora Pearson, 9ª ed., 2011. CHAOS. "Summary for 2010", [online]. www.standishgroup.com, 2010. Veiga, E. G. "Um modelo de processo para o desenvolvimento de programas para TV digital e interativa. Dissertação – UFPB, 2006. Marconi, M.A, Lakatos, E. "Fundamentos de metodologia científica". Ed.Atlas,SP,2003. Travassos, G.H. "Introdução à engenharia de software experimental". Relatório técnico RT-ES-590/02, COPPE/UFRJ, 2002. Snyder, C. "paper prototyping: the fast and easy way to design and refine user interfaces", Morgan Kaufmann, 2003. Soares Neto, A. S., Soares, L. F. G., Rodrigues, R. F., Barbosa, S. D. J. "Construindo programas audiovisuais interativos utilizando a NCL 3.0 e a ferramenta Composer". Telemídia / PUC – Rio, 2ª ed., 2007. Sánchez, I. F. H. "Quadrados Latinos com aplicações em engenharia de software". Dissertação (Mestrado) – UFPE, Recife, 2011. 129