Experimentation of the Model Driven RichUbi Process in the Adaptive Rich Interfaces Development
-
Upload
luciana-zaina -
Category
Technology
-
view
67 -
download
2
Transcript of Experimentation of the Model Driven RichUbi Process in the Adaptive Rich Interfaces Development
Experimentação do Processo Experimentação do Processo Model Driven Model Driven RichUbiRichUbi no Desenvolvimento de Interfaces no Desenvolvimento de Interfaces
Ricas AdaptativasRicas Adaptativas
Experimentação do Processo Experimentação do Processo Model Driven Model Driven RichUbiRichUbi no Desenvolvimento de Interfaces no Desenvolvimento de Interfaces
Ricas AdaptativasRicas AdaptativasCarlos Eduardo Cirilo
Antonio Francisco do PradoLuciana Aparecida Martinez Zaina
Wanderley Lopes de Souza
Universidade Federal de São CarlosCCET – Centro de Ciências Exatas e de Tecnologia
PPG-CC – Programa de Pós-Graduação em Ciência da Computação
Available in: http://dx.doi.org/10.1109/SBES.2011.20
2
AgendaAgenda• Introdução– Motivação– Processo Model Driven RichUbi
• Experimentação– Definição– Planejamento– Execução– Análise dos Resultados– Ameaças à Validade
• Considerações FinaisXXV Simbósio Brasileiro de Engenharia de Software
INTRODUÇÃOINTRODUÇÃO
http://www.psdgraphics.com/file/single-white-puzzle.jpg
4
MotivaçãoMotivação• Computação Ubíqua– Heterogeneidade de dispositivos de acesso– Necessidade de adaptação das aplicações
XXV Simbósio Brasileiro de Engenharia de Software
5
MotivaçãoMotivação• Interfaces Ricas Computação Ubíqua– Versões especializadas v1
v2
v3
v4
v5
XXV Simbósio Brasileiro de Engenharia de Software
6
MotivaçãoMotivação• Interfaces Ricas Computação Ubíqua– Versões especializadas
• Sensibilidade ao Contexto– Adaptação da aplicação
(comportamento e conteúdo) conforme o contexto da interação
– Pode-se adaptar a interface de acordo com o perfil do dispositivo de acesso
XXV Simbósio Brasileiro de Engenharia de Software
7
MotivaçãoMotivação• Desenvolvimento Dirigido a Modelos (MDD)– Foco na modelagem da aplicação
• Maior nível de abstração– Geração de código a partir dos modelos
• Transformações Modelo para Código (M2C)– Redução dos esforços de desenvolvimento
[LUCRÉDIO, 2009]XXV Simbósio Brasileiro de Engenharia de Software
8
Processo Processo Model Driven RichUbiModel Driven RichUbi• Model Driven Process to Construct Rich Interfaces
for Context-Sensitive Ubiquitous Applications– Apoio na construção de interfaces ricas de
aplicações ubíquas que se adaptam conforme o perfil do dispositivo recuperado do contexto
– Simplificar o desenvolvimento de aplicações ubíquas sensíveis ao contexto• Foco na construção das interfaces ricas adaptativas
– Aumentar a produtividade– Reduzir os esforços de desenvolvimento
XXV Simbósio Brasileiro de Engenharia de Software
9
Processo Processo Model Driven RichUbiModel Driven RichUbi• Características– Modelagem é realizada com base em um
metamodelo do Domínio de Interfaces Ricas DSL– Geração parcial de código a partir dos modelos– Uso de adaptadores dinâmicos de conteúdo– Estratégia de adaptação híbrida:• Adaptação Estática + Dinâmica
XXV Simbósio Brasileiro de Engenharia de Software
10
Processo Processo Model Driven RichUbiModel Driven RichUbi• Visão Geral
XXV Simbósio Brasileiro de Engenharia de Software
EXPERIMENTAÇÃO DO PROCESSO EXPERIMENTAÇÃO DO PROCESSO MODEL DRIVEN RICHUBIMODEL DRIVEN RICHUBI
http://informationexpress.com.au/wp-content/uploads/2009/07/41.-Jigsaw.jpg
12
ExperimentaçãoExperimentação• Método experimental [WOHLIN et al., 2000]
1. Definição2. Planejamento 3. Execução4. Análise dos Resultados
• Estudo comparativo entre o uso do Model Driven RichUbi e o uso do ciclo de vida clássico, sem aplicar MDD, para a construção de interfaces ricas adaptativas
XXV Simbósio Brasileiro de Engenharia de Software
13
ExperimentaçãoExperimentação• Aplicação ubíqua, nomeada TrackMe, para o
rastreamento de pessoas
XXV Simbósio Brasileiro de Engenharia de Software
14
1. Definição do Experimento1. Definição do Experimento• Objetivo– Analisar o uso do Model Driven RichUbi na
construção das interfaces ricas adaptativas de uma aplicação ubíqua;
– Com o propósito de avaliação;– Com respeito à eficiência (Ɛ) em termos de tempo
despendido (τ) e produtividade (Ϸ);– Do ponto de vista de desenvolvedores de
software;– No contexto de estudantes de graduação em
Ciência e Engenharia da Computação.
XXV Simbósio Brasileiro de Engenharia de Software
15
2. Planejamento do Experimento2. Planejamento do Experimento• Seleção do Contexto
– Ambiente universitário
• Formulação das Hipóteses– Hipótese nula (H0): Em geral, não há diferença entre equipes
utilizando o processo Model Driven RichUbi e equipes utilizando o processo baseado no ciclo de vida clássico para a construção de interfaces ricas adaptativas, com respeito à eficiência (Ɛ) da equipe.H0: ƐRichUbi = ƐClássico μ⇒ τRichUbi = μτClássico e μϷRichUbi = μϷClássico
– Hipótese alternativa (H1): Equipes utilizando o processo Model Driven RichUbi para a construção de interfaces ricas adaptativas são, em geral, mais eficientes do que equipes utilizando o ciclo de vida clássico.H1: ƐRichUbi > ƐClássico μ⇒ τRichUbi < μτClássico e μϷRichUbi > μϷClássico
– Hipótese alternativa (H2): Equipes utilizando o ciclo de vida clássico para a construção de interfaces ricas adaptativas são, em geral, mais eficientes do que equipes utilizando o processo Model Driven RichUbi.H2: ƐRichUbi < ƐClássico μ⇒ τRichUbi > μτClássico e μϷRichUbi < μϷClássicoXXV Simbósio Brasileiro de Engenharia de Software
16
2. Planejamento do Experimento2. Planejamento do Experimento• Seleção das Variáveis– Dependente• Eficiência da equipe
– Independentes• Aplicação = TrackMe; • Ambiente de desenvolvimento = IDE Eclipse; • Tecnologias = Java, JavaServer Faces , eXtensible
Hypertext Markup Language (XHTML), Cascading Style Sheets (CSS), JavaScript e biblioteca jQuery.• Processo de Desenvolvimento
– Model Driven RichUbi– Ciclo de vida clássico
Fator
XXV Simbósio Brasileiro de Engenharia de Software
17
2. Planejamento do Experimento2. Planejamento do Experimento• Seleção dos participantes
– 31 alunos do 3º e 4º anos de graduação dos cursos de Bacharelado em Ciência e Engenharia da Computação da UFSCar, matriculados na disciplina Tópicos em Informática II
• Projeto do Experimentoem blocos (blocking) um fator (processo)
com dois tratamentos completamente randomizado
XXV Simbósio Brasileiro de Engenharia de Software
18
3. Execução do Experimento3. Execução do Experimento• Preparação– Elaboração da instrumentação
• Objetos: projeto parcial da aplicação, SQL do BD, artefatos de apoio ao processo, etc...
• Diretrizes: formulários de caracterização e de consentimento, descrição da tarefa, descrição da aplicação e material de apoio;
• Instrumentos para coleta de dados
– Treinamentos
XXV Simbósio Brasileiro de Engenharia de Software
19
3. Execução do Experimento3. Execução do Experimento• Execução
Dado LegendaHIAProj Hora de Início da Atividade de ProjetoHTAProj Hora de Término da Atividade de ProjetoHIAImpl Hora de Início da Atividade de ImplementaçãoHTAImpl Hora de Término da Atividade de ImplementaçãoHIATeste Hora de Início da Atividade de TestesHTATeste Hora de Término da Atividade de TestesLCGAuto Linhas de Código Geradas Automaticamente
LCGManual Linhas de Código Geradas Manualmente
83%
13%
XXV Simbósio Brasileiro de Engenharia de Software
20
4. Análise e Interpretação dos Resultados4. Análise e Interpretação dos Resultados• Teste das Hipóteses– t-test
• Checar na tabela padrão de distribuição estatística t de Student• Grau de significância α (risco de rejeitar H0 em caso de esta ser
verdadeira)• Graus de liberdade (gl = m + n – 2)XXV Simbósio Brasileiro de Engenharia de Software
21
• Teste das Hipóteses
– Estatística:• t0τ = -2,7148
• α = 0,055• t0.0275,8 = 2,6899
– Desde que |t0τ| > t0.0275,8 foi possível rejeitar a hipótese nula H0τ com 5,5% de significância
Tempo Total (τ)
Entrada Duas amostras independentes: XτRichUbi = {1.52, 1.25, 0.9, 0.73, 0.60} e YτClássico = {1.75, 1.57, 1.50, 1.40, 1.30} (dados em horas).
H0τH0τ: μτRichUbi = μτClássico, i.e., os valores médios para os tempos totais dos grupos de ambos os processos são iguais.
Critério de
Rejeição de H0τ
H1τ: μτRichUbi < μτClássico; H2τ: μτRichUbi > μτClássico;Logo, μτRichUbi ≠ μτClássico (bicaudal): rejeitar H0τ se |t0τ| > tα/2,glτ
4. Análise e Interpretação dos Resultados4. Análise e Interpretação dos Resultados
XXV Simbósio Brasileiro de Engenharia de Software
22
• Teste das Hipóteses
– Estatística:• t0Ϸ = 3,4806
• α = 0,02• t0.01,8 = 3,3554
– Desde que |t0Ϸ| > t0.01,8 foi possível rejeitar a hipótese nula H0Ϸ com 2% de significância
Produtividade (Ϸ)
Entrada Duas amostras independentes: XϷRichUbi = {233, 196, 367, 225, 487} e YϷClássico = {133, 56, 115, 86, 129}.
H0ϷH0Ϸ: μϷRichUbi = μϷClássico, i.e., os valores médios para as produtividades dos grupos de ambos os processos são iguais.
Critério de
Rejeição de H0Ϸ
H1Ϸ: μϷRichUbi > μϷClássico; H2Ϸ: μϷRichUbi < μϷClássico;Logo, μϷRichUbi ≠ μϷClássico (bicaudal): rejeitar H0Ϸ se |t0Ϸ| > tα/2,glϷ
4. Análise e Interpretação dos Resultados4. Análise e Interpretação dos Resultados
XXV Simbósio Brasileiro de Engenharia de Software
23
• Conclusões do Experimento– μτRichUbi < μτClássico e μϷRichUbi > μϷClássico H1 pode ser
validada em detrimento da hipótese H2
• Ambiente in-vitro– Limitação ao escopo de desenvolvedores de
software em ambiente universitário• Generalização para contexto mais amplo
requer:– Novos estudos em ambientes in-vivo com mais
equipes– Comparação com outras abordagens de
desenvolvimento (e.g. LPS, métodos ágeis)
4. Análise e Interpretação dos Resultados4. Análise e Interpretação dos Resultados
XXV Simbósio Brasileiro de Engenharia de Software
24
• Validade de Conclusão– Conclusões corretas a respeito do efeito dos
tratamentos nas variáveis dependentes• escolha do método estatístico adequado para análise;
cuidados tomados na execução e na medição do experimento
– t-test – Medidas coletadas envolvendo dados diretos
(hora, LOC)– Heterogeneidade da experiência dos participantes
tratada pela estratégia de blocos (blocking)
Ameaças à ValidadeAmeaças à Validade
XXV Simbósio Brasileiro de Engenharia de Software
25
• Validade Interna– Assegurar que os resultados foram, de fato,
obtidos em decorrência dos tratamentos• modo como os participantes são selecionados,
agrupados, recompensados e tratados; situação em que ocorre o experimento
– Estudantes da área de Computação em um estágio avançado de seus cursos de graduação (3º e 4º anos)
– Blocking por nível de experiência– Nenhuma recompensa quanto à nota da disciplina– Sessão única e simultânea com todos os grupos
Ameaças à ValidadeAmeaças à Validade
XXV Simbósio Brasileiro de Engenharia de Software
26
• Validade de Construção– Generalizar o resultado do experimento ao
conceito ou teoria envolvidos no estudo• definição adequada das medidas e tratamentos
– Processo de desenvolvimento eficiência da equipe• LOC, hora
– Não foram divulgadas as métricas de interesse aos participantes (produtividade e tempo)• Evitar interações voltadas para maximização ou
minimização das métricas com o intuito de favorecer ou prejudicar o experimento
Ameaças à ValidadeAmeaças à Validade
XXV Simbósio Brasileiro de Engenharia de Software
27
• Validade Externa– Generalizar os resultados do experimento para um
contexto mais amplo– Três riscos principais:• Escolha errada dos participantes• Ambiente inapropriado• Período de tempo que afete os resultados
Ameaças à ValidadeAmeaças à Validade
XXV Simbósio Brasileiro de Engenharia de Software
CONSIDERAÇÕES FINAISCONSIDERAÇÕES FINAIS
http://www.websbook.com/sc/upimg/allimg/081108/027_1600x1200_websbook.jpg
29
• Alinhamento com os benefícios das abordagens de MDD– Maior produtividade e redução de esforços
• Replicação do experimento em ambiente industrial (in-vivo)– Consideração de novos fatores– Verificação de novos efeitos (e.g. qualidade das
interfaces)
• Pacote de experimentação– http://www.dc.ufscar.br/~carlos_cirilo/package-mdrichubi.zip
Considerações FinaisConsiderações Finais
XXV Simbósio Brasileiro de Engenharia de Software
30
ObrigadoObrigado!Carlos Eduardo Cirilo
Antonio Francisco do [email protected]
Luciana Ap. Martinez [email protected]
Wanderley Lopes de [email protected]