1) O documento descreve um experimento para avaliar o uso do processo Model Driven RichUbi na construção de interfaces ricas adaptativas comparado ao uso do ciclo de vida clássico.
2) O experimento envolveu 31 estudantes divididos em grupos para desenvolver uma aplicação de rastreamento de pessoas usando os dois processos.
3) A análise estatística dos resultados mostrou que os grupos que usaram o processo Model Driven RichUbi tiveram maior produtividade e menor tempo de desenvolvimento em comparação aos grupos que usaram o
Interaction With Mobile Devices by Elderly People: The Brazilian Scenario
Experimentation of the Model Driven RichUbi Process in the Adaptive Rich Interfaces Development
1. Experimentação do ProcessoExperimentação do Processo Model DrivenModel Driven
RichUbiRichUbi no Desenvolvimento de Interfacesno Desenvolvimento de Interfaces
Ricas AdaptativasRicas Adaptativas
Experimentação do ProcessoExperimentação do Processo Model DrivenModel Driven
RichUbiRichUbi no Desenvolvimento de Interfacesno Desenvolvimento de Interfaces
Ricas AdaptativasRicas Adaptativas
Carlos Eduardo Cirilo
Antonio Francisco do Prado
Luciana Aparecida Martinez Zaina
Wanderley Lopes de Souza
Universidade Federal de São Carlos
CCET – 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. 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 Finais
XXV Simbósio Brasileiro de Engenharia de Software
4. 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
6. 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. 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. 8
ProcessoProcesso 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. 9
ProcessoProcesso 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
11. EXPERIMENTAÇÃO DO PROCESSOEXPERIMENTAÇÃO DO PROCESSO
MODEL DRIVEN RICHUBIMODEL DRIVEN RICHUBI
http://informationexpress.com.au/wp-content/uploads/2009/07/41.-Jigsaw.jpg
12. 12
ExperimentaçãoExperimentação
• Método experimental [WOHLIN et al., 2000]
1. Definição
2. Planejamento
3. Execução
4. 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
14. 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. 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.
XXV Simbósio Brasileiro de Engenharia de Software
16. 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. 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 Experimento
em blocos (blocking) um fator (processo)
com dois tratamentos
completamente randomizado
XXV Simbósio Brasileiro de Engenharia de Software
18. 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. 19
3. Execução do Experimento3. Execução do Experimento
• Execução
Dado Legenda
HIAProj Hora de Início da Atividade de Projeto
HTAProj Hora de Término da Atividade de Projeto
HIAImpl Hora de Início da Atividade de Implementação
HTAImpl Hora de Término da Atividade de Implementação
HIATeste Hora de Início da Atividade de Testes
HTATeste Hora de Término da Atividade de Testes
LCGAuto Linhas de Código Geradas Automaticamente
LCGManual Linhas de Código Geradas Manualmente
83%
13%
XXV Simbósio Brasileiro de Engenharia de Software
20. 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)XXV Simbósio Brasileiro de Engenharia de Software
21. 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 H 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. 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 H 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. 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. 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. 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. 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. 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
29. 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
Considerando essas motivações, propomos o processo dirigido a modelos, que denominamos Model Driven RichUbi, para apoiar a construção...
No processo, a modelagem...
Uma característica importante do processo é que, buscando reduzir o número de versões que são produzidas em tempo de desenvolvimento, no Model Driven RichUbi é adotada uma estratégia híbrida para adaptação das interfaces combinando adaptação estática com adaptação dinâmica.
Requisitos são mapeados em algumas poucas versões da interface, cada qual apropriada para um determinado grupo de dispositivos (adaptação estática)
Adaptadores de conteúdo são empregados para, em tempo de execução, selecionar a versão estática mais apropriada ao perfil do dispositivo e adaptá-la conforme suas particularidades (adaptação dinâmica)
A parte da adaptação estática é facilitada com a geração de código a partir da modelagem para diferentes tecnologias (através do reúso do metamodelo e das transformações M2C)
A parte da adaptação dinâmica é facilitada com o emprego dos adaptadores de conteúdo (através do reúso desses componentes)
O processo é realizado em duas etapas principais: Engenharia de Domínio e Engenharia de Aplicação.
A ED engloba as atividades para a construção dos artefatos reutilizáveis que apoiam o desenvolvimento das aplicações ubíquas com interfaces ricas adaptativas. Esses artefatos compreendem um metamodelo do Domínio de Interfaces Ricas que expressa para apoio à modelagem, transformações para geração de código e adaptadores de conteúdo das interfaces.
As atividades da EA estendem as disciplinas de Análise, Projeto, Implementação e Testes dos processos de software convencionais, incorporando o reúso dos artefatos produzidos na ED, e concentram-se no desenvolvimento das interfaces ricas adaptativas.
A ideia do processo é a de que, uma vez realizada a ED, os artefatos produzidos poderão ser reutilizados na EA para o desenvolvimento de aplicações em diferentes domínios de problema.