WTDSoft - CBSoft 2013 - Universidade de Brasília

Transcrição

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 Geração de Portfólios em
Linhas de Produto de Software
Jonathas Jivago de Almeida Cruz1
Orientadores: Pedro de Alcântara dos Santos Neto1 ,
Ricardo de Andrade Lira Rabêlo 2
1
Programa de Pós-Graduação em Ciência da Computação
Laboratório de Engenharia de Software e Informática Industrial (EASII)
Departamento de Ciência da Computaçã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
Previsão da Qualificação: agosto de 2013
Previsão de Conclusã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. Caracterização do Problema
Linhas de Produto de Software (LPS) é uma abordagem da Engenharia de Software
(ES) que permite o desenvolvimento de sistemas de software por meio da reutilização
de artefatos. Essa abordagem proporciona vários benefı́cios em termos de redução no
custo de desenvolvimento, melhoria na qualidade do software, melhoria na estimação de
custos e redução no tempo de lançamento [Pohl et al. 2005][Schmid 2002].
De acordo com [Pohl et al. 2005], o sucesso de uma organização está diretamente
relacionado com o gerenciamento de seus produtos, uma vez que, compreende aspectos de
desenvolvimento, produção e comercialização de uma linha de produto e suas aplicações.
A determinação do tamanho da arquitetura da linha envolve atividades que limitam o sistema pela definição de quais comportamentos devem ou não estar presentes. Essas atividades são conhecidas como escopo [Clements and Northrop 2002]. Existem três
tipos de escopo, que são: Escopo do Portfólio de Produtos (EPP), Escopo de Domı́nio
(ED) e Escopo de Ativos (EA). O EPP é 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, é importante destacar que a
adoção dessa abordagem envolve um alto custo em sua fase inicial. As decisõ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 portfólio considerando tanto aspectos de satisfação do cliente e custos
de desenvolvimento dos produtos é um problema NP-Difı́cil [White et al. 2009], sendo
portanto, intratável por té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 consideração o uso técnicas de Inteligência Computacional (IC). Tais técnicas são
relevantes para problemas com um grande espaço de busca como o EPP.
Conforme as argumentações apresentadas anteriormente e a importância do planejamento do EPP para o sucesso da adoção de LPS, este trabalho de mestrado tem por objetivo propor uma abordagem hı́brida que combina té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 é utilizada para buscar os produtos com um custo mı́nimo e com
uma maior relevância para os consumidores. As relevância para os produtos são obtidos
por meio do uso de Software Quality Function Deployment (SQFD) [Haag et al. 1996].
Pretendemos com o uso dessa abordagem gerar um portfólio contendo os melhores produtos em termos de lucratividade, proporcionando uma maior satisfação aos consumidores.
O restante deste artigo está organizado da seguinte forma: na Seção 2 é apresentada a fundamentação teórica que aborda os principais conceitos relacionados a este
trabalho; na Seção 3 são detalhadas as contribuições esperadas; na Seção 4 os trabalhos
relacionados são descritos; na Seção 5 tem-se a apresentação do estado atual do trabalho;
e por fim, na Seção 6 é descrita a metodologia de avaliação dos resultados.
18
2. Fundamentação Teórica
2.1. Linhas de Produto de Software
Conforme a definição exposta na Seção 1, uma LPS é uma abordagem de reuso de software que permite o desenvolvimento de sistemas de software por meio do reuso sistemático de artefatos [Pohl et al. 2005].
Organizações que adotam LPS para o desenvolvimento de seus produtos obtém
vários ganhos dentre eles [Schmid 2002]: redução no custo de desenvolvimento, no tempo
de lançamento, no esforço de manutenção, além de melhorias na qualidade do software e
no planejamento.
Apesar dos vários benefı́cios providos pelas LPS, alguns problemas ameaçam a
adoção dessa abordagem como: o custo inicial necessário para criar uma plataforma
reusável e problemas relacionados ao gerenciamento dos produtos linha, dentre eles,
destacamos o escopo de portfólio de produtos.
2.2. Sistemas de Inferência Fuzzy
Os Sistemas de Inferência Fuzzy (SIF) ou Sistemas Fuzzy (SF) são capazes de lidar com
processos altamente complexos, os quais são representados pela imprecisão, incerteza e
informações qualitativas. Normalmente, Sistemas de Inferência Fuzzy são baseados em
regras linguı́sticas do tipo ”se condição então ação”, no qual a teoria dos conjuntos fuzzy
[Zadeh 1965] e a lógica fuzzy [Zadeh 1996] proveem o ferramental matemático necessário
para lidar com informaçõ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 variáveis de entrada o
nı́vel de acoplamento entre os ativos, o numero de linhas de código e a complexidade
ciclomática. Utilizamos também um outro SIF para estimar a qualidade dos produtos
gerados usando o custo de desenvolvimento do produto e o seu nı́vel de satisfação para o
cliente como variáveis de entrada.
As regras de produção em um SIF tem variáveis linguı́sticas ambos em seus antecedentes e em seus consequentes. Com o uso de SIF do tipo Mamdani é 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] é um algoritmo baseado em Algoritmos Genéticos (AG)
projetado para resolver problemas multiobjetivos.
O NSGA-II inicia gerando uma população inicial P0 de tamanho N , ordenada de
acordo com um operador de dominância. Uma segunda população, chamada de Q0 , com
o mesmo tamanho de P0 , é gerada aplicando-se os operadores de crossover e mutação
sobre P0 . As duas populações são combinadas em uma terceira população chamada R0 ,
com tamanho 2N . A população R0 é ordenada usando o operador de dominância. Então,
uma população P1 é populada com as frentes de Pareto. As frentes de Pareto são geradas
usando o operador de distância sobre a população R0 . A população P1 é então usada
como a população inicial para a próxima geração do algoritmo. O processo continua até
que o critério de parada ser alcançado.
19
2.4. Software Quality Function Deployment (SQFD)
O SQFD [Liu 2000] é uma técnica que permite melhorar o desenvolvimento de software
por meio da aplicação de té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 técnicos e prioriza esses aspectos de acordo com a sua
importância. No contexto de uma LPS, os aspectos técnicos são representados pelos ativos
do sistema, tais ativos podem ser código fonte, documentos, modelos, etc. Neste trabalho,
utilizamos as classes do sistema como aspectos té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 importância dos aspectos
técnicos (classes). Por fim, é possı́vel obter a importância de um dado produto com base
no conjunto de classes que o compõe. Ressalta-se que a importância dada por um consumidor depende de qual segmento o mesmo está inserido. Desta forma, um mesmo produto
poderá ter diferentes nı́veis de relevância dependendo do segmento de mercado.
3. Resultados Esperados e Contribuições
De acordo com o exposto na Seção 1, este trabalho propõe uma nova abordagem para
resolver um dos problemas de gerenciamento de produtos de uma linha, especificamente,
o problema de escopo de portfólio. As principais contribuições de nosso trabalho são
descritas a seguir:
• A aplicação de um método quantitativo, baseado em questionários, para obter a
relevância atribuı́da pelos consumidores às caracterı́sticas do sistema. Destacase que os consumidores são estratificados em grupos, representando assim, os
segmentos do mercado;
• Uso de um método (SQFD) sistemático para obter o nı́vel de relevância de cada
um dos ativos (classes do sistema). Com este método podemos obter a relevância
de um produto com base nos nı́veis de importância dado pelos consumidores às
caracterı́sticas;
• Aplicação de um SIF para estimar o custo de desenvolvimento de um ativo, tendo
como entradas métricas utilizadas no desenvolvimento de software;
• Uso da metaheurı́stica NSGA-II para buscar produtos, candidatos ao portfólio,
que possuam um menor custo de desenvolvimento e com uma maior relevância
para os consumidores de um segmento;
• Aplicação de um SIF para estimar o melhor produto de cada segmento, utilizando
como variáveis de entrada o custo de desenvolvimento de um produto e a sua
relevância;
• Avaliaçã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 é uma
ferramenta open source amplamente utilizada para projetar sistemas usando UML.
A nossa abordagem é composta por cinco etapas: (i) Inferir o custo de desenvolvimento
dos ativos; (ii) Calcular a relevância dos ativos para cada segmento; (iii) Calcular os produtos candidatos à pertencer ao portfó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 realização da abordagem será feita por meio da implementação de uma ferramenta desenvolvida em nosso
laboratório.
Destacamos que desenvolvemos tal ferramenta e avaliamos a geração de portfólios
em um trabalho preliminar [Cruz et al. 2013]. A avaliação deste trabalho foi conduzida
sobre o sistema JBook-SPL que é uma adaptação do sistema JBook3 para ser uma SPL.
Porém, o JBook-SPL é uma LPS com apenas 1 KLOC e que apresenta apenas granularidade no nı́vel de classes entre as caracterı́sticas e os ativos.
Até o momento da escrita deste artigo, a nova ferramenta está em fase final de
construção, no qual está sendo implementado questões pontuais nas etapas i e ii. Estas
questões referem-se a um caráter dinâmico, pois a relevância e o custo de desenvolvimento dos ativos vão ser variáveis. Esse caráter dinâmico existe devido ao ArgoUMLSPL possuir diferentes nı́veis de granularidade entre as caracterı́sticas e os ativos.
Esses nı́veis de granularidades são representados por métricas que são geralmente
utilizadas para avaliar a implementação de LPS baseadas em pré-processadores. As granularidades podem ser no nı́vel de pacote, classe, interface de método, método, corpo de
método, assinatura de método, instrução, atributo e expressão [Couto et al. 2011].
Schmid [Schmid 2002] propô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 não aborda
o escopo de portfólio de produto.
O trabalho de Helferich [Helferich et al. 2005] faz uso de técnicas de QFD para
fazer o planejamento de portfólio de produtos. O QFD é utilizado para elencar as principais caracterı́sticas dos produtos da linha por meio de questionários, além de identificar
os segmentos dos consumidores com base em suas prioridades. Este trabalho não aborda
aspectos de custo de desenvolvimento dos produtos.
A abordagem proposta por [Muller 2011] visa otimizar o portfólio de produtos
em termos de maximização de lucro. Um programa matemático é proposto no qual
as variáveis Willingness To Pay (WTP) dos consumidores, custos dos ativos, preços de
seus produtos e de concorrentes são considerados. Apesar de ser relatado que os clientes
atribuem diferentes valores de importância aos produtos dependendo de seu segmento,
tal importância não é considerada na formulação matemática proposta. Uma avaliação
empı́rica realizada, releva o impacto para o lucro de cada um dos ativos além de identificar os melhores produtos.
6. Avaliação dos Resultados
A avaliação dos resultados será conduzida sobre a LPS ArgoUML-SPL. O ArgoUMLSPL é uma LPS extraı́da da ferramenta ArgoUML, utilizada para o projeto de sistemas
usando UML.
Ressaltamos que o uso do ArgoUML-SPL para a avaliação e validação dos resultados é 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 não-funcionais e por
possuir vários nı́veis de granularidade entre as caracterı́sticas e os ativos.
Referê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., Bö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
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.
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.
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
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 ÓS -G RADUAÇ ÃO EM C I ÊNCIA DA C OMPUTAÇ ÃO
U NIVERSIDADE F EDERAL DE C AMPINA G RANDE
A PRIMORANDO A VERIFICAÇ Ã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, conclusã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, verificação de conformidade entre código e especificação vem ganhando maior interesse, dada a necessidade de
prover maior qualidade ao cliente. As não–conformidades que estejam presentes em sistemas formalmente especificados devem ser detectadas o quanto antes,
para manter a qualidade do sistema. Existem tanto soluções dinâmicas quanto
estáticas para a verificação de não-conformidades em código Java anotado com
JML (Java Modeling Language), uma instância da programação baseada em
contratos. Contudo essas soluções não apresentam qualquer facilidade para a
categorização das não-conformidades detectadas; essa tarefa é realizada manualmente demandando bastante tempo e esforço por parte do programador. Com
um mecanismo que torne essa atividade ao menos semiautomática estaremos
contribuindo para o desenvolvimento de sistemas que utilizem programação
por contratos como forma de aprimorar o projeto dos programas, e por consequência, sua qualidade geral. O presente trabalho de Mestrado tem como objetivos o aprimoramento do método baseado em análise dinâmica concretizado
pela ferramenta JMLOK, adicionando-lhe um módulo para a categorização das
não-conformidades detectadas e o relato de estudos de caso e experimentos
avaliando o potencial desta ferramenta e de seu método de aplicação.
Palavras–chave: programação por contratos, conformidade, categorização.
SBES
29
1. Caracterização do Problema
No contexto de verificação baseada em contratos, as não-conformidades existentes entre
o código e sua especificação formal devem ser detectadas o quanto antes, para que a qualidade do sistema seja mantida e assegurada. Contudo as soluções atualmente existentes
(tanto dinâmicas quanto estáticas) não apresentam qualquer facilidade para a classificação
dessas não-conformidades; sendo essa tarefa realizada manualmente pelo programador,
demandando bastante tempo e esforço. Com um mecanismo que (semi) automaticamente
categorize as não–conformidades essa tarefa se tornará mais prática.
2. Fundamentação Teórica
2.1. Design by Contract
A ideia fundamental do Design by Contract (DBC) [Meyer 1992a] é que um módulo
cliente (que dependa de determinada funcionalidade(s) de outro(s) módulo(s)) e um fornecedor (cuja funcionalidade seja utilizada por outro(s) módulo(s)) têm um contrato entre
si estabelecendo direitos e obrigações de cada módulo. Dessa forma o módulo cliente,
antes da chamada de um módulo fornecedor, deve garantir propriedades relacionadas aos
parâmetros de entrada desse fornecedor (as pré-condições dos métodos); o módulo fornecedor por sua vez, deve garantir propriedades relacionadas ao resultado da sua execução
com os dados do cliente (as pós-condições dos métodos).
Uma das primeiras implementações conhecidas para linguagens Orientadas a
Objeto (O.O.) de DBC foi implementada em Eiffel [Meyer 1992b]. Atualmente,
a metodologia é empregada para várias linguagens (Java [Leavens et al. 1999], C#
[Barnett et al. 2004], dentre outras).
Uma grande vantagem de DBC é que, dado que pré e pós-condições sejam especificadas no código de modo que possam ser verificadas por um compilador, qualquer
violação do contrato entre o módulo cliente e o fornecedor pode ser detectada imediatamente, permitindo a construção de sistemas mais confiáveis e de maior qualidade.
2.2. Conformidade
No contexto da verificação dos contratos surge o conceito de conformidade [Cheon 2007]:
o código satisfaz a sua especificação. No Listing 1 é apresentado um trecho de código
que satisfaz sua especificação. Já não-conformidade é um código que não satisfaz a sua
especificação; conforme apresentado posteriormente no Listing 2. Os casos nos quais não
ocorre conformidade entre código e especificação são:
1. Quando o cliente garante as pré-condições e o fornecedor não garante as póscondições - uma violação do contrato por parte do fornecedor;
2. Quando o cliente não garante as pré-condições do fornecedor - neste caso uma
violaçã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 é especificado com o uso de
asserções tais como pré-condições, pós-condições e invariantes. Estas asserções podem
ser utilizadas para verificar se o código está em conformidade com sua especificação (se
os contratos entre as classes/interfaces estão sendo respeitados), aumentando a confiabilidade na qualidade do programa.
No Listing 2 é apresentado um trecho de código de um sistema que é especificado
em JML. O sistema possui como um de seus componentes uma classe do tipo GenerationCounter que possui 3 métodos: updateCount que atualiza o número de gerações se o
seu parâmetro receber o valor true (indicando a criação de uma geração), resetCount que
reinicia o contador de gerações, e o construtor da classe. Essa classe possui um invariante
- claúsula invariant de que o número de gerações estará 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 código Java anterior não está em conformidade com sua especificação
JML. Considere a sequê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 ( 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 é v i o l a d o .
Após cinco chamadas ao método updateCount com true como parâmetro, o invariante será violado. Este problema de não-conformidade só é evidenciado por meio de
chamadas sucessivas ao método updateCount num único caso de teste. O exemplo é pequeno, e tal erro possivelmente seria detectado pelo desenvolvedor. Porém, em sistemas
reais, não-conformidades mais sutis podem ser de difı́cil identificação, tornando de grande
valia o uso de ferramentas automáticas para testes de verificação de conformidade.
As principais formas existentes para verificação de conformidade entre código-fonte
e especificação são: manualmente por meio da definição de leis para prova formal da conformidade, conforme apresentado no trabalho de Freitas [Freitas 2009];
31
com o uso de ferramentas para checagem estática das especificações (como o ESC/Java [Flanagan et al. 2002]); e, de forma dinâmica com o uso de testes de unidade para
checar conformidade entre o código e sua especificação.
As ferramentas para verificar conformidade entre código Java e especificação
JML de modo dinâmico diferem basicamente no processo utilizado para a geração
dos dados de teste; quanto ao processo de geração de casos de teste, este é realizado de modo aleatório. A seguir serão apresentadas as formas de geraçã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 [Varjão et al. 2011].
A ferramenta JMLUnit, foi uma das primeiras ferramentas para verificação de
conformidade entre código Java e especificação JML. Ela realiza a geração dos dados
de teste para tipos primitivos Java por meio de chamadas aos métodos sob teste combinando valores para seus parâmetros de entrada. Na ferramenta JMLUnitNG, que foi uma
evolução da ferramenta JMLUnit, os dados de teste são gerados com o uso de Java reflection. Na ferramenta JET há a utilização de algoritmos genéticos para a geração dos dados
de teste. Por fim, na ferramenta JMLOK a geração dos dados de teste é realizada de modo
completamente automático e aleatório.
Apesar da grande utilidade das ferramentas (apresentadas na Seção 3) na identificação
das não-conformidades entre código Java e especificação JML, elas ainda não dão suporte
à categorização automática dessas não-conformidades; no exemplo apresentado no Listing 2, as ferramentas poderiam identificar que há uma não-conformidade entre o código
e sua especificação (não é possı́vel afirmar se o erro é advindo da especificação ou do
código-fonte; mas pretendemos ajudar a apontar a causa do erro) e reportariam que houve
um erro de um determinado tipo de JML; contudo não forneceriam ao programador qualquer outra informação que o auxiliasse a depurar o problema ocorrido. Essas ferramentas
fornecem apenas informações relacionadas à linha do código, o nome do método e da
classe onde a não-conformidade foi detectada. Todo o processo de categorização é realizado manualmente: o programador, de posse das informações de onde foi detectada
a não-conformidade, vai ao código-fonte, inspeciona o trecho de código onde foi detectado o problema e o categoriza de acordo com seu impacto no programa. Visando tornar
esse processo mais prático, recentemente propusemos um modelo para a classificação de
não-conformidades, com suas causas prováveis. As categorias e suas causas são:
• invariant error - quando a não-conformidade é causada por uma pré-condição
fraca ou um invariante forte ou um null-related (um atributo que não foi inicializado ou que recebe o valor null);
• precondition error - quando se trata de uma não-conformidade JMLInternalPreconditionError (quando a violação da pré-condição ocorre no corpo de um
método, não tendo sido causada por um dado de entrada criado automaticamente
pela ferramenta de teste que viola a pré-condição de um determinado método) e é
causada por uma pré-condição forte ou uma pós-condição fraca;
• postcondition error - quando causada por uma pré-condição fraca ou uma póscondição forte;
32
• evaluation error - quando há o lançamento de uma exceção que torna inválida uma
expressão a ser avaliada numa pré- ou pós-condição ou invariante;
• constraint error - quando ocasionada por uma restrição histórica forte ou uma
pré-condição fraca ou um null-related.
Essa falta de uma abordagem mais detalhada para auxiliar na categorização das
nã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 especificação JML (que
chamamos de KLJML) consistindo de programas-exemplo (Samples) disponı́veis no repositório JML1 e programas reais: Bomber, JAccouting, JSpider [Rebêlo et al. 2009], HealthCard [Rodrigues 2009], Mondex [Tonin 2007] e TransactedMemory [Poll et al. 2002]
disponı́veis na literatura; e detectamos 79 não-conformidades. As não-conformidades
detectadas foram categorizadas segundo o nosso modelo e reportadas aos autores das
unidades experimentais; os autores nos reportaram que estão de acordo com nossa
categorização.
Realizamos també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 não-conformidades; além disso fizemos
uma comparação estatı́stica entre as ferramentas para determinar qual apresentava melhor
desempenho em relação ao número de nã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 confiança. Com estes experimentos pudemos verificar que as
ferramentas existentes apenas relatam o tipo de erro que ocorreu na execução de determinado caso de teste, não auxiliando o programador a descobrir se os erros advém das
mesmas falhas. Assim, a parte de depuração dos erros reportados fica a cargo de uma
atividade manual do programador verificar o código-fonte do método no qual o erro fora
encontrado e checar se os demais erros são advindos de uma mesma falha.
5. Contribuições
Os principais objetivos do presente trabalho são auxiliar no processo de categorização
de não-conformidades detectadas entre código-fonte Java e especificação JML, por meio
do aprimoramento da ferramenta JMLOK adicionando-lhe um módulo para realizar a
categorização das não-conformidades detectadas; a realização de experimentos comparando o total de coincidências entre a categorização manual (realizada por um especialista seguindo o modelo proposto) e a categorização automática dividido pelo total de
não-conformidades detectadas, e a realização de estudos de caso para avaliar a eficácia
do método de categorização proposto. Entendemos que isso é essencial para identificar
pontos fracos na nossa proposta e justificar melhor os pontos fortes. O feedback gerado
por estes estudos servirá para ajustar os resultados e o suporte ferramental antes do final
do projeto de Mestrado. Como objetivos secundários temos a modularização da ferramenta e a realização de melhorias no processo utilizado para geração de testes. Com isso,
estaremos contribuindo para o desenvolvimento de sistemas que utilizem programação
por contratos como forma de aprimorar o projeto dos programas, e por consequência, sua
qualidade geral.
1
http://www.eecs.ucf.edu/ leavens/JML/examples.shtml
33
Referê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.
Rebêlo, H., Lima, R., Corné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.
Varjã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.
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.
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
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
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.
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
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.
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.
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.
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
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
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
Educao”. In: Revista Novas Tecnologias na Educao – 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 Nvel Mdio”. XIII Workshop de
Educao em Computao (WEI’2005). So 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.
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.
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.
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.
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 Ströder, Carsten Otto, and Jü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 Rü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
Otimizações de Código Sensı́veis ao Contexto de Chamada
Matheus Silva Vilela ([email protected])
Mestrado em Ciência da Computação
Departamento de Ciência da Computação – UFMG – Brasil
Orientador: Fernando Magno Quintão Pereira ([email protected])
Data de ingresso: março/2012
Previsão de Conclusão: março/2014
Data de aprovação da proposta: fevereiro/2013
Palavras-chave: otimizaçã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 são essenciais para otimizar código, deixando para o programador a tarefa de projetar algoritmos, abstraindo a complexidade das micro-otimizações.
Os compiladores de hoje são capazes de gerar código quase tão eficiente quanto aquele
feito por um programador de assembly experiente. Entretanto, a maioria das otimizações
feitas por compiladores são independentes de contexto. O contexto da chamada de uma
função é o caminho dinâmico de execução do inı́cio do programa até o ponto em que a
função é chamada. Realizar otimizações sensı́veis ao contexto é difı́cil, já que existem
muitos contextos que o compilador deve levar em consideração. Nesse trabalho , propomos um avanço no estado-da-arte dos algoritmos que realizam otimizações sensı́veis
ao contexto. Nosso objetivo é realizar otimizações sensı́veis ao contexto especı́ficas. Se
obtivermos sucesso, esperamos projetar e implementar um novo tipo de otimizador de
código, responsável por clonar funções, usando o melhor clone em cada um dos contextos de chamada.
100
1. Introdução
As diferenças nos contextos de chamada das funções proporcionam novas oportunidades de otimização de código. Intuitivamente, se um segmento de código pudesse ser
otimizado de acordo com suas diferenças de comportamento em diferentes contextos
de chamada, a performance do programa, como um todo, seria melhorada. Entretanto,
otimizações clássicas de compiladores não consideram o contexto de chamada para aplicar suas transformações. A limitação dos compiladores, nesse caso, deve-se à sensibilidade ao contexto. A integração de procedimentos, ou inlining de funções, é uma forma
que compiladores possuem de mitigar tal problema. Entretanto, a integração de procedimentos pode levar a um crescimento exponencial do programa transformado. Além disso,
funções recursivas não podem ser integradas [Keith D. Cooper 2012, pg.458]. Nesse trabalho, nós propomos uma solução simples e completamente automática para realizar algumas otimizações sensı́veis ao contexto especı́ficas.
O objetivo deste trabalho é implementar e testar uma técnica, baseada na clonagem
de funções, que leva em consideração os contextos de chamada para aplicar otimizações
especı́ficas. Em essência, procuraremos separar os pontos de chamada de funções em
duas classes de equivalência: a primeira, denominada promissora, contém as chamadas
que podem se beneficiar de uma otimização especı́fica, enquanto a segunda, denominada
inócua, contém as chamadas para as quais tal otimização não se aplique. Para cada função
otimizável, criaremos um clone, que terá seu código melhorado por uma otimização especı́fica. As chamadas promissoras serão substituı́das por chamadas da função modificada, enquanto as chamadas inócuas continuarão invocando a função original.
Implementamos algumas das técnicas descritas neste trabalho no compilador
LLVM [Lattner and Adve 2004]. Os resultados obtidos até agora mostram-se promissores. O alcance das otimizações propostas é impressionante, podendo ser aplicadas em
até um terços das funções disponı́veis em SPEC CPU 2006. Os ganhos de desempenho,
entretanto, foram pequenos: os programas melhorados ficaram, em média, menos que 2%
mais rápidos. Consideramos aqui que ambos os programas, original e transformado, são
compilados com LLVM -O2. Especulamos que os ganhos pequenos devem-se ao fato de
termos realizado essas otimizações sobre SPEC CPU 2006, uma coleção de programas
já muito otimizados. Para testar tal hipótese, aplicamos nossas técnicas sobre aplicações
de código aberto, obtendo resultados notáveis. Por exemplo, quando aplicadas a alguns
benchmarks da companhia Adobe, as otimizações propostas levaram a ganhos de desempenho de até 31.2%.
2. Otimizações Propostas
Conforme discutimos na seção anterior, neste trabalho pretendemos experimentar algumas otimizações baseadas na clonagem de funções. Nesta seção, descreveremos cada
uma das otimizações de código já implementadas.
Eliminação de Valores de Retorno não Usados. Em um programa, podem existir
contextos onde o valor retornado por uma função não é utilizado. Na linguagem C, isso
pode acontecer quando uma função retorna mais de um resultado para o programador, por
meio de ponteiros passados como parâmetro, e somente um desses valores é interessante.
Além disso, o programador pode estar interessado somente no efeito colateral gerado pela
101
função, não se importando com o valor de retorno. Nesses casos, seria interessante que
nenhuma das instruções usadas para calcular tal valor fossem executadas.
Nessa otimização, propomos a criação de um clone otimizado para as funções que
sejam chamadas em contextos onde seu valor de retorno não seja armazenado. Nosso
clone possui seu valor de retorno do tipo void, e não possui qualquer computação usada
para determinar o antigo valor de retorno. O reconhecimento de contextos promissores
nesse caso é simples: uma chamada r = f (. . .) pode ser substituı́da se o nome que ela
define como retorno – r – é código morto. A detecção de código morto dá-se segundo
uma análise clássica de código que omitimos por brevidade [Appel and Palsberg 2002,
p.417].
Distinção de Apontadores. Na linguagem C, é comum o uso de apontadores como
parâmetros de funções. Entretanto, como apontadores podem se sobrepor, eles comprometem o alcance das otimizações que um compilador pode aplicar sobre uma função.
O uso do modificador restrict pode, nesses casos, trazer benefı́cios para a
otimização do código. Esse modificador é um recurso que o desenvolvedor possui para
informar ao compilador que um ponteiro não possui sinônimos no escopo da função em
que é parâmetro formal. Dessa forma, o compilador fica livre para otimizar mais agressivamente o código. Embora essa otimização seja muito localizada, seus resultados são
formidáveis. Experimentos realizados com funções simples que recebem dois ou mais
ponteiros como parâmetro revelam que o uso do modificador restrict pode aumentar a
eficiência de um código em até três vezes.
Nessa otimização, propomos a criação de um clone de funções que recebem dois
ou mais ponteiros como parâmetros, especializando-o de forma a adicionar o modificador restrict aos parâmetros. A fim de reconhecer contextos promissores para distinção
de apontadores, deve-se determinar se os ponteiros usados como parâmetros reais são
sinônimos ou não. Com esse intuito, implementamos e utilizamos a análise de apontadores de Andersen [Andersen 1994], aplicando a otimização somente quando nenhum dos
apontadores se sobrepõem.
Nı́vel de Sensibilidade a Contexto. As otimizações propostas nesse texto são disparadas
por uma análise sensı́vel ao contexto do tipo 0-CFA [Shivers 1988]. Em outras palavras,
nosso contexto é formado por somente um nı́vel de chamada de função. Somos capazes de distinguir uma chamada de função de outra, mas não somos capazes de distinguir
invocações em sequências de duas ou mais chamadas aninhadas de função. Tal decisão
acarreta em um custo mais baixo para aplicar as otimizações. Embora não tenhamos implementado a distinção de nı́veis mais profundos de contextos de invocação, especulamos,
partindo dos resultados obtidos por Lhotak et al. [Lhoták and Hendren 2006], que nı́veis
extra aumentariam muito pouco o alcance de nossas otimizações.
3. Resultados Experimentais
Esta seção descreve uma série de experimentos que realizamos para validar tanto a
eliminação de valores de retorno não usados quanto a distinção de apontadores. As
otimizações foram testada em uma máquina com 12 nú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 otimizações foram implementadas sobre LLVM 3.3. Os testes
que mostramos nesta seçã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. Sequência de transformações que usamos para aplicar a clonagem de
funções.
Implementação das Otimizações A figura 1 descreve a sequência de transformações
pela qual passa um programa que otimizamos. Cada uma dessas otimizações contém três
etapas:
1. Identificação: são reconhecidas as funções que, devido à algum contexto de chamada, podem se beneficiar da clonagem.
2. Clonagem: é criado um clone para cada função marcada na etapa anterior.
3. Substituição: chamadas promissoras são substituı́das por chamadas da função
clonada.
Findas essas três etapas, aplicamos sobre o programa transformado as otimizações disponı́veis em LLVM -O2. São essas otimizações que irão, efetivamente, polir o código da
função clonada. Por exemplo, ao eliminarmos o valor de retorno de uma função, nós não
removemos as computações necessárias ao seu cálculo. Deixamos tal tarefa a cargo de
LLVM -O2. Durante nossos experimentos, nós omitimos a integração de procedimentos
(inlining) desse conjunto de otimizações. Fizê-mo-lo porque a integração de procedimentos torna difı́cil medir os ganhos obtidos por nossa otimização, uma vez que muitas das
chamadas das funções originais e clonadas são removidas do programa. Finalmente, antes de produzirmos um executável, nós eliminamos os chamados clones órfãos. Se todas
as chamadas de uma função clonada forem promissoras, então a versão original daquela
função deixará de ser alcançável. Tais funções – denominadas órfãs – são eliminadas
nessa etapa final.
Variação no tempo de execução. A figura 2 mostra a variação no tempo de execução
dos programas devido a nossas otimizações. Os tempos de execução foram obtidos com
um intervalo de confiança de 95.0%, tendo sido coletadas dez amostras por programa examinado. Estamos comparando os programas obtidos após a aplicação do último estágio
mostrado na figura 1, com os programas obtidos via a aplicação de todas as otimizações
presentes em LLVM -O2. A média geométrica de ganho, devido a distinção de apontadores, foi de 1.59%. Nosso melhor resultado, nesse caso, foi 6.10% obtido sobre
483.xalancbmk, e nosso pior número foi -1,83% em 453.povray. Nós não pudemos obter resultados conclusivos com a eliminação de valores de retorno: a maior parte
de nossos resultados ficaram dentro de uma margem de variação de -1.0% e +1.0%.
Especulamos que esses resultados tı́midos devem-se ao fato de estarmos testando nossas otimizações sobre os programas disponı́veis em SPEC CPU 2006.
103
Figura 2. Variação no tempo de execução dos benchmarks devido à distinção de
apontadores. Barras representam percentual de ganhos entre LLVM -O2 mais
nossa otimização, e LLVM -O2 sem ela. Quanto maior a barra, maior o ganho
conseguido por nossa otimização.
Esses programas foram escritos por profissionais experts, e vêm sendo gradualmente melhorados desde longa data. Em outros benchmarks menos otimizados pudemos registrar ganhos maiores. Por exemplo, a companhia Adobe possui uma coleção de seis programas usados em testes de desempenho publicamente
disponı́veis em http://stlab.adobe.com/performance/. Ao aplicarmos
a distinção de apontadores sobre esses programas, pudemos obter um ganho de
31.20% em um deles, loop unroll.c. Registramos também ganhos em outros três: simple types loop.c (3.81%), functionobjects.c (3.86%) e
simple types const.c (4.15%).
Decidimos averiguar o porquê de a eliminação de valores de retorno não surtir
maior efeito nos programas encontrados em SPEC CPU 2006. Com tal intuito, observamos que muitas funções clonadas usam o valor de retorno somente para indicar sucesso
na execução. Dessa forma, muitos clones tiveram somente a instrução de retorno, por
exemplo, “ret 1”, substituı́da por “ret void”.
A ideia de clonar funções para que otimizações dependentes de contexto possam ser
aplicadas sobre o seu código não é nova. Em seu recente livro texto, Grune et al., por
exemplo, descrevem a clonagem como uma forma de aumentar o alcance da propagaçã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 dissertação de doutorado [Hall 1991, Cp.5]. Nesse caso, a clonagem é comumente chamada especialização
de código. A técnica de Hall pode ser descrita como especialização estática. A contraparte dinâmica existe também. Costa et al. mostraram como clonar funções no contexto
104
da compilação just-in-time para realizar a propagação de constantes em código especializado [de Assis Costa et al. 2013]. Ainda assim, é surpreendentemente difı́cil encontrar,
na literatura de linguagens de programação, discussões sobre a clonagem de funções para
a implementação de otimizações dependentes de contexto. Compiladores industriais, tais
como icc e LLVM não utilizam a clonagem. Os compiladores gcc e open64 podem realizar a clonagem de uma função que possui somente um sı́tio de invocação, e que recebe
constantes como parâmetros.
5. Conclusão e Trabalhos Futuros
Neste trabalho, propomos otimizações especı́ficas capazes de tirar proveito do contexto
onde funções são chamadas para gerar um código mais eficiente. Duas otimizações foram implementadas e testadas. A primeira delas lida com funções cujo valor de retorno
não é usado. A segunda promove a distinção dos apontadores passados como parâmetros
de funções. Para aplicar nossas otimizações somente em contextos promissores, recorremos à clonagem e especialização de funções. Nossos experimentos mostraram que as
transformações propostas são capazes de aumentar a eficiência de programas, ainda que
aplicadas sobre os nı́veis mais altos de otimização de um compilador industrial. Pretendemos desenvolver outras otimizações baseadas em clonagem que sejam sensı́veis ao contexto de chamada das funções. Como futuras otimizações, vislumbramos a substituição
de parâmetros por constantes e a eliminação de escritas desnecessárias em parâmetros.
Todo o código utilizado em nossos experimentos encontra-se publicamente disponı́vel na
página https://code.google.com/p/clone-based-opts/.
Referê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.
Lhotá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
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.
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.
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
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.
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.
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 ç 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 ç
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 ç 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 ç 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 ç 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 ç 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 ç a ˜ o , p e r m i t i n d o
a s s i m s u a a d o ç 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 ç 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 ç 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 ç 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 ç 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 ç 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 ç 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 ç a˜ o
p l i c a ç
a b s tra
a rtic ip
in s titu
o ˜ e s v eˆ m
ç a˜ o ( c a a ç a˜ o d e
i ç o ˜ e s .
a r t y , a e x e c u ç 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 ç 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 ç 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 ç 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 ç 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
ç 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 ç o ˜ e s
A s p r i n c i p a i s c o n t r i b u i ç 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 ç 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 ç 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 ç a˜ o
e is p o n
e n ta is
s e n t a ç 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 ç 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 ç 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 ç 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 ç a˜
i c a d e a p l i c a ç 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 ç 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 ç 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 á 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 ¸ ã o d a s t é c n i c a s d e i n t e r a c ¸ ã 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 ç 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 ç 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 ç 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 ç 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 ç 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 ç 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 ç a˜ o a S M a r t y , l e v a n d o a e v o l u ç 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 ç 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 ç 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 ç 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 ç 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 ç 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 ç 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 ç 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 ç 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 ç 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 ç 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 ç 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 ç 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 ç 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 ç 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 ç 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 ç 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 ç 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 ç a˜ o d a s m u d a n ç 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
ç 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
ç 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 ç 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” (no
conheo), 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

WTDSoft - CBSoft 2013 - Universidade de Brasília

Transcrição

Documentos relacionados

GEQ060 - Laboratório de Engenharia Química 2

EQQ30 - Laboratório de Engenharia Química 2

Correção da Unicamp 2009 2ª fase - Inglês feita pelo Intergraus

Receita Federal Brasileira publica Instrução Normativa 1.277 que

Editorial - Centro Hospitalar do Barlavento Algarvio, EPE

SD5109

COMUNICAÇÃO TÉCNICA Nº 173774 Production of O/W

Linux x Windows

Gallaudet University - Universidade Federal de Santa Catarina

o problema mente-corpo através das abordagens psico