universidade nove de julho programa de pÓs...
TRANSCRIPT
UNIVERSIDADE NOVE DE JULHO
PROGRAMA DE PÓS-GRADUAÇÃO EM INFORMÁTICA E GESTÃO DO
CONHECIMENTO
RENATO ALVES FERREIRA
CONCEPÇÃO E TESTE DE APLICATIVO MÓVEL DE MODELAGEM E
SIMULAÇÃO A EVENTOS DISCRETOS
SÃO PAULO
2018
UNIVERSIDADE NOVE DE JULHO
PROGRAMA DE PÓS-GRADUAÇÃO EM INFORMÁTICA E GESTÃO DO
CONHECIMENTO
RENATO ALVES FERREIRA
CONCEPÇÃO E TESTE DE APLICATIVO MÓVEL DE MODELAGEM E
SIMULAÇÃO A EVENTOS DISCRETOS
Dissertação apresentada ao Programa de Pós-Graduação em Informática e Gestão do Conhecimento da Universidade Nove de Julho - UNINOVE, como parte dos requisitos necessários para a obtenção do título de Mestre em Informática.
Prof. Dr. Fábio Henrique Pereira – Orientador
SÃO PAULO 2018
Ferreira, Renato Alves.
Concepção e teste de aplicativo móvel de modelagem e simulação a
eventos discretos. / Renato Alves Ferreira. 2018.
114 f.
Dissertação (mestrado) – Universidade Nove de Julho - UNINOVE,
São Paulo, 2018.
Orientador (a): Prof. Dr. Fábio Henrique Pereira.
1. Modelagem e simulação. 2. Eventos discretos. 3. Mobile App.
4. Teste de software. 5. Qualidade de software.
I. Pereira, Fábio Henrique. II. Titulo
CDU 658.5
Dedico este trabalho aos meus amados pais, Reinaldo Alves Ferreira (in memoriam) e Maria Margarida Ferreira.
AGRADECIMENTOS
Primeiramente, ao meu Deus e senhor Jesus Cristo, pela vida e por permitir mais esta conquista.
À minha amada família, meus filhos Karoline Alves Ferreira e Lucas Alves Ferreira e esposa Andrea de Souza Alves, pelo apoio, colaboração e paciência em minhas ausências.
À minha mãe, Maria Margarida Ferreira, pelas orações e palavras de incentivo nos momentos de dificuldades.
Ao meu orientador Prof. Dr. Fábio Henrique Pereira, pela presteza, dedicação, companheirismo e os conhecimentos transmitidos.
Aos professores do Programa de Pós-Graduação em Informática e Gestão do conhecimento.
E, finalmente, a Universidade Nove de Julho, pela oportunidade de estudo e gratuidade do curso.
“Em seu coração o homem planeja seu caminho, mas o Senhor lhe dirige os passos.”
(Provérbios, 16:9)
RESUMO
Com o avanço tecnológico das últimas décadas, em especial a evolução dos
dispositivos móveis, os tablets e smartphones se tornaram muito populares e
excelentes ferramentas tecnológicas. No entanto, aplicativos de qualidade são
sempre esperados e necessários, em especial em áreas nas quais são escassos ou
inexistentes, como modelagem e simulação a eventos discretos. Entretanto, para
atender aos critérios de confiabilidade necessários nessa área, processos de
melhoria de qualidade devem ser adotados, como os que tratam da concepção de
software e testes para a computação móvel. Nesse sentido, o desafio não se resume
apenas a escolher e adotar ferramentas que tornem os processos de testes
automáticos. Dentro desse contexto, o que se propôs neste trabalho é levantar as
características essenciais e inerentes a uma ferramenta de modelagem e simulação
a eventos discretos e, a partir dessas características, conceber um protótipo de um
aplicativo móvel e aplicar procedimentos de testes de software para sua avaliação.
Para tanto, inicialmente foi aplicada uma pesquisa exploratória, investigando
trabalhos que correlacionassem a área de estudo com os vários temas envolvidos,
em busca de técnicas e ferramentas automáticas de testes que pudessem realizar
procedimentos confiáveis e eficientes em uma aplicação tão específica.
Posteriormente foi realizada uma pesquisa experimental, a fim de se averiguar o
comportamento das funcionalidades implementadas no protótipo e dos processos de
testes de software no ambiente móvel. Os resultados obtidos demonstram a
eficiência e dificuldades encontradas ao submeter uma aplicação com
funcionalidades tão específicas a testes de qualidade de software.
Palavras chave: Modelagem e simulação, Eventos discretos, Mobile App, Teste de
software, Qualidade de software.
LISTA DE FIGURAS
Figura 1: Tipos de testes mais usados ...................................................................... 16
Figura 2: Diferentes tipos de simulação. ................................................................... 18
Figura 3: Estrutura do sistema de filas com um canal de serviço .............................. 20
Figura 4: Estrutura do sistema de filas com três canais de serviço ........................... 20
Figura 5: Etapas de um modelo de simulação .......................................................... 23
Figura 6: Fases do processo e simulação ................................................................. 25
Figura 7: Etapas e procedimentos da pesquisa ........................................................ 34
Figura 8: Etapas para criação de modelos de simulação .......................................... 37
Figura 9: Painel de objetos ........................................................................................ 41
Figura 10: Parametrização de objetos ....................................................................... 43
Figura 11: Modelo gerado dinamicamente ................................................................ 43
Figura 12: Animação da simulação ........................................................................... 44
Figura 13: Resultados da simulação ......................................................................... 45
Figura 14: Visão geral dos testes .............................................................................. 46
Figura 15: Visão geral de cada fase dos testes ......................................................... 48
Figura 16: Tela do servidor Appium .......................................................................... 49
Figura 17: Tela de configuração de seção no Appium .............................................. 55
Figura 18: Tela de acompanhamento do teste do Appium ........................................ 56
Figura 19: Tela de utilização dos scripts em uma aplicação Java ............................. 57
Figura 20: Ilustração da execução automática do teste de software ......................... 58
Figura 21: Protótipo de simulador SIMUNI9 .............................................................. 60
Figura 22: Parametrização dos objetos ..................................................................... 61
Figura 23: Modelo gerado dinamicamente ................................................................ 62
Figura 24: Comportamento dos números com distribuição Exponencial ................... 67
Figura 25: Comportamento dos números com distribuição Normal ........................... 67
Figura 26: Comportamento dos números com distribuição Triangular ...................... 67
Figura 27: Modelagem no Arena ............................................................................... 71
Figura 28: Modelagem no Simuni9 ............................................................................ 71
Figura 29: Resultados da simulação no Arena .......................................................... 71
Figura 30: Resultados da simulação no Simuni9 ...................................................... 72
Figura 31: Características e subcaracterísticas da norma ISO/IEC 9126-1 .............. 81
Figura 32: Características e subcaracterísticas da norma ISO/IEC 25010 ............... 85
Figura 33: IDE Android Studio ................................................................................... 92
Figura 34: Algoritmo com distribuição exponencial ................................................... 96
Figura 35: Algoritmo com distribuição normal ........................................................... 96
Figura 36: Algoritmo com distribuição triangular ....................................................... 97
Figura 37: Algoritmo modelo de sistema de fila – Parte 1 ......................................... 98
Figura 38: Algoritmo modelo de sistema de fila – Parte 2 ......................................... 99
LISTA DE QUADROS
Quadro 1: Exemplos de normas e padrões relacionadas a software ........................ 12
Quadro 2: Ferramentas de teste de software para ambiente Android ....................... 15
Quadro 3: Características dos softwares de simulação ............................................ 29
Quadro 4: Descrição dos módulos de simulação ...................................................... 42
Quadro 5: Características objetivas que devem ser observadas .............................. 51
Quadro 6: Avaliação manual das características do protótipo .................................. 63
LISTA DE TABELAS
Tabela 1: Amostra dos números pseudoaleatórios gerados ..................................... 66
Tabela 2: Comparativo do p-value em cada experimento ......................................... 68
Tabela 3: Comparativo de resultados de simulação ente o Arena e o Simuni9 ........ 70
Tabela 4: Avaliação dos IDEs ................................................................................... 93
LISTA DE ABREVIATURAS E SIGLAS
ABNT Associação Brasileira de Normas Técnicas
API Application Programming Interface
APP Application
CMMI Capability Maturity Model Integration
DSDM Dynamic Systems Development Method
FCFS First Come First Served
FIFO First In First Out
IDE Integrated Development Environment
IEC International Electrotechnical Commission
IEEE Institute of Electrical and Electronic Engineers
ISO International Organization for Standardization
LIFO Last In First Out
MPS-BR Melhoria de Processo de Software – Brasileiro
NBR Norma Brasileira
PRI Priority Service
SIRO Service In Random Order
SQuaRE Systems and Software Quality Requirements and Evaluation
SUMÁRIO
Pág.
1. Introdução .............................................................................................................. 1
1.1 Contextualização do tema .................................................................................. 1
1.2 Problema de pesquisa ....................................................................................... 4
1.3 Objetivo geral ..................................................................................................... 4
1.4 Objetivos específicos ......................................................................................... 4
1.5 Justificativa da pesquisa .................................................................................... 5
1.6 Limitações e delimitação da pesquisa ................................................................ 6
2. Fundamentação teórica ........................................................................................ 9
2.1 Conceito de software ......................................................................................... 9
2.2 Aplicativos para dispositivos móveis ................................................................ 10
2.3 Qualidade de software ..................................................................................... 11
2.3.1 Normas de referência de qualidade de software ISO/IEC 9126-1 e 25010 12
2.3.2 Concepção e prototipação de software ............................................................... 13
2.4 Testes de softwares para dispositivos móveis ................................................. 14
2.5 Modelagem e simulação computacional .......................................................... 16
2.6 Sistemas de filas .............................................................................................. 19
2.7 Etapas para a criação de modelos de simulação ............................................. 22
2.8 Ferramentas de modelagem e simulação computacional ................................ 26
2.8.1 Características dos softwares de modelagem e simulação ........................... 27
2.8.2 Números pseudoaleatórios estatisticamente distribuídos .............................. 30
3. Materiais e métodos ............................................................................................ 32
3.1 Materiais adotados na pesquisa....................................................................... 32
3.2 Etapas e procedimentos da pesquisa .............................................................. 33
4. Resultados ........................................................................................................... 40
4.1 Concepção do protótipo Simuni9 ..................................................................... 40
4.1.1 Painel de objetos ...................................................................................................... 41
4.1.2 Seleção e parametrização de objetos ................................................................. 42
4.1.3 Construção dos modelos de simulação .............................................................. 43
4.1.4 Números aleatórios confiáveis .............................................................................. 44
4.1.5 Animação do modelo de simulação ..................................................................... 44
4.1.6 Relatórios gerados após a simulação ................................................................. 45
4.2 Procedimentos para testes de aplicativo móvel ............................................... 46
4.2.1 Teste automático – preparação do cenário de testes ...................................... 49
4.2.2 Teste manual ............................................................................................................. 50
4.2.3 Teste Híbrido ............................................................................................................. 52
4.3 Aplicação dos testes de software e análise dos resultados ............................. 54
4.3.1 Aplicação da avaliação automática das funcionalidades seleção,
parametrização dos objetos e execução da simulação. ............................................ 54
4.3.2 Aplicação da avaliação manual das funcionalidades painel de objetos,
construção dos modelos e animação da simulação ................................................... 60
4.3.3 Aplicação da avaliação híbrida das funcionalidades geração de números
aleatórios, execução do modelo e relatórios gerados................................................ 65
5. Conclusão e trabalhos futuros ........................................................................... 73
5.1 Conclusão ........................................................................................................ 73
5.2 Trabalhos futuros ............................................................................................. 74
Referências .............................................................................................................. 75
APÊNDICE A – Detalhamento das normas ISO/IEC 9126-1 e ISO/IEC 25010 ..... 81
APÊNDICE B – Testes para definição do ambiente de desenvolvimento
integrado .................................................................................................................. 90
APÊNDICE C – Algoritmos adotados para a criação do protótipo Simuni9 ....... 94
1
1. Introdução
Neste capítulo são apresentados a contextualização do tema, o problema de
pesquisa, os objetivos gerais e específicos, a justificativa, bem como as limitações e
delimitações da pesquisa.
1.1 Contextualização do tema
A evolução tecnológica nas últimas décadas permitiu inovações e
aperfeiçoamentos em muitas áreas do conhecimento, seja pela adoção de novas
técnicas, métodos, softwares, ou na utilização de dispositivos e equipamentos
modernos, em especial na área dos dispositivos móveis.
Os tablets e smartphones tornaram-se muito populares e excelentes
ferramentas tecnológicas acompanhadas por inúmeros aplicativos que os
acompanham ou são disponibilizados em repositórios, os apps-store, que são lojas
virtuais mantidas pelos fabricantes de sistemas operacionais para mobile. Segundo
Joorabchi, Mesbah, Kruchten (2013), até a conclusão de suas pesquisas, existiam
cerca de 800 mil aplicativos móveis na loja app-store da Apple para iPhone, 650 mil
na Google Play Store para Android, 120 mil na Windows Marketplace para Windows
Phone e 100 mil na loja Blackberry Appworld. Já em outra pesquisa, Statista (2017)
informa que o número de aplicativos disponíveis para download nas duas principais
lojas virtuais evoluíram para a casa dos milhões, sendo 2,8 milhões para o sistema
Android e 2,2 milhões para iPhone. As plataformas Windows Phone e Blackberry
atingiram a marca de 669 mil e 234 mil aplicativos respectivamente.
Após uma busca realizada em um dos apps-store citados, o Google Play
Store, foram encontrados 210 aplicativos categorizados como científicos pela loja
virtual. Como exemplo: o Touch Surgery, destinado a anatomia humana, entre vários
outros ligados à área da medicina como, MedScape, Epocates e Gestatools; Like
That Garden para reconhecimento e classificação de plantas por foto; Star Walk
para reconhecimento de astros celestes pela câmera do dispositivo; PhotoMath que
realiza cálculos automáticos apenas analisando a imagem da operação matemática;
Estatística Fácil, OR e Estatística Pro para aplicações em estatística, entre outros.
2
Apesar da grande disponibilidade de aplicativos, muitas áreas científicas
ainda são desprovidas de algum tipo de aplicativo mais específico e confiável, como
no segmento da modelagem e simulação computacional.
Ao almejar o desenvolvimento de aplicativos eficientes e de qualidade,
normas ou técnicas de desenvolvimento e ferramentas de testes de software podem
atuar para garantir que os mesmos façam o que se espera de maneira funcional e
correta ao que se propõem. A norma ISO 9000/2000, por exemplo, define qualidade
como o grau em que um conjunto de características inerentes a um produto,
processo ou sistema cumpre os requisitos inicialmente estipulados para eles (MARÍN
e OLALLA, 2011). Nesse aspecto, para o desenvolvimento de um pretenso aplicativo
que atue como uma ferramenta para a área da modelagem e simulação a eventos
discretos no ambiente dos dispositivos móveis, inicialmente é necessário um estudo
das características essenciais que tal aplicativo deve contemplar, de tal forma que
possibilite estabelecer e aplicar uma proposta para a fase de concepção, além de
contribuir na definição de procedimentos de teste de software apropriados para sua
avaliação.
Com relação ao processo de testes de software, para atender aos critérios de
confiabilidade necessários nessa área, o desafio não se resume apenas a escolher e
adotar métodos de testes ou ferramentas que tornem os processos de testes
automáticos, o que parece não ser uma tarefa fácil e trivial, visto que muitos
desenvolvedores ainda optam por testes manuais (JOORABCHI, MESBAH,
KRUCHTEN, 2013) e (TAO E GAO 2016). É fundamental, além disso, desenvolver e
aplicar procedimentos de teste de software que possa avaliar as características
específicas e essenciais de um aplicativo de modelagem e simulação a eventos
discretos.
Um aplicativo desse tipo deve contemplar funcionalidades bem peculiares,
como gerar números pseudoaleatórios com distribuições de probabilidades
estatísticas confiáveis, parametrização de comportamentos de objetos gráficos de
simulação, permitir criação de modelos de simulação com praticidade, animação que
ilustre a simulação e relatórios elucidativos. Não é possível garantir a eficiência
dessas funcionalidades sem a adoção de procedimentos de teste de software
adequados, que consigam aferir todas as características importantes da aplicação.
3
Segundo Datas et al. (2009) implementar teste de software para dispositivos
móveis exige uma adaptação no processo de teste tradicional. Essa adaptação se
faz necessária devido ao fato de que não é possível executar testes da mesma
maneira que se realizam testes de softwares em computadores. Uma das
dificuldades é a grande variedade de modelos, fabricantes e plataformas
operacionais que dificultam a padronizações no ambiente de testes automatizados.
Segundo Tao e Gao (2016) a medida que mais aplicações são construídas, os
engenheiros de software precisam de mais métodos de validação de qualidade e
ferramentas de testes automáticas para lidar com os problemas e desafios
relacionados.
Nesta pesquisa, as buscas na literatura foram por trabalhos que
correlacionassem as áreas da modelagem e simulação computacional a eventos
discretos, dispositivos móveis, desenvolvimento e testes de softwares para
dispositivos móveis. Na aparente ausência de trabalhos correlatos envolvendo tais
áreas, foram colhidas produções específicas em cada uma delas, a fim de tentar
direcionar as pesquisas para o foco deste trabalho.
No campo da modelagem e simulação a eventos discretos, encontram-se na
literatura, trabalhos pelos quais vários softwares para computadores são abordados
e já estão consolidados como ferramentas tecnológicas importantes, como o Arena,
ProModel, AutoMod, entre outros, mas no universo dos dispositivos móveis nada foi
encontrado. O mais próximo desse contexto, é um serviço online, chamado
ClouDES (PADILLA et al., 2014), mas para se criar modelos de simulação,
necessita-se de conexão eficiente e permanente com a Internet, registro e
autenticação constante junto a entidade desenvolvedora. Em experimentos
realizados constatou-se que, se o mesmo for acessado de um dispositivo móvel, seu
desempenho é prejudicado sensivelmente e apresenta pouca praticidade de
manipulação de seus componentes em telas tão reduzidas, agravado ainda por
serem acessados diretamente de navegadores de Internet, trazendo prejuízos à
utilização geral.
No segmento de teste de software para dispositivos móveis, foram colhidos
trabalhos que tratassem o assunto, mas igualmente sem qualquer correlação com
aplicativos voltados para área da modelagem e simulação computacional ou que
4
pudessem testar algumas das funcionalidades mais peculiares que um aplicativo
deste tipo exige. Exemplifica-se, a pesquisa de Hu et al. (2014) que apresentam uma
aplicação chamada AppDoctor para testes de aplicativos Android que promete
ajudar os desenvolvedores a diagnosticar erros nos aplicativos que estão em
desenvolvimento, mas apenas em funcionalidades mais genéricas. Outros trabalhos
sobre teste de software para dispositivos móveis são apresentados no capítulo 2.
A literatura traz uma variedade de trabalhos sobre desenvolvimento e
experimentos de testes de softwares para computadores e em menor proporção,
para dispositivos móveis. Porém não foram encontrados trabalhos com abordagens
para a concepção, desenvolvimento e testes de aplicativos voltados para a área da
modelagem e simulação computacional a eventos discretos ou mesmo sobre a
existência de aplicativos específicos de simulação no ambiente dos dispositivos
móveis.
1.2 Problema de pesquisa
Quais as características de uma ferramenta de modelagem e simulação a
eventos discretos precisam ser consideradas para garantir a qualidade de
uma aplicação para dispositivos móveis, considerando os aspectos funcionais e de
eficiência, tratadas pelas normas ISO/IEC 9126-1 e 25010?
1.3 Objetivo geral
O objetivo deste trabalho é conceber um protótipo e procedimentos de teste
de software de um aplicativo para dispositivos móveis a partir do estudo das
características essenciais e inerentes a uma ferramenta de modelagem e simulação
a eventos discretos considerando os aspectos funcionais e de eficiência, segundo as
normas de referência ISO/IEC 9126-1 e 25010.
1.4 Objetivos específicos
Analisar as características fundamentais de uma ferramenta de modelagem e
simulação a eventos discretos, a fim de se levantar conhecimento necessário quanto
às funcionalidades essenciais dessas ferramentas.
5
Construir um protótipo de aplicativo móvel em sistema Android, com a
implementação das funcionalidades essenciais e inerentes a um simulador de
eventos discretos para avaliar o comportamento e o funcionamento geral do
aplicativo nesse ambiente.
Submeter as funcionalidades do protótipo a procedimentos de testes de
software apresentados neste trabalho.
Avaliar a viabilidade de um aplicativo definitivo para atuar como uma
ferramenta para a área da modelagem e simulação computacional a eventos
discretos no ambiente dos dispositivos móveis.
1.5 Justificativa da pesquisa
Os softwares para modelagem e simulação computacional atualmente
disponíveis para computadores, possuem vários recursos e de eficácia consolidada,
mas não foram projetados para atuarem na plataforma mobile, que oferece muito
mais liberdade, facilidades e menor custo para os seus usuários. No modelo
tradicional, há dependência de espaços físicos e outros recursos mais dispendiosos,
como o uso em laboratórios ou outros ambientes.
A versatilidade e praticidade na utilização dos dispositivos móveis como
ferramenta tecnológica pode ser um ganho considerável em muitas áreas.
Especificamente para o segmento dos simuladores de eventos discretos, tendo a
possibilidade da mobilidade na utilização da ferramenta in loco, por exemplo,
podendo criar ou ajustar modelos de simulação estando presente no ambiente
modelado e tendo um envolvimento mais direto com o sistema real que está sendo
simulado, entre outras vantagens que esses dispositivos oferecem.
Na literatura pesquisada nota-se uma ausência de trabalhos que tratam o
tema da pesquisa, relacionando modelagem e simulação computacional com
dispositivos móveis, desenvolvimento e testes de softwares. Uma contribuição
importante para essa área é dispor de um aplicativo especifico em que possa ser
utilizado para realizar simulações de eventos discretos, como o que trata dos
sistemas de filas, no ambiente dos dispositivos móveis.
6
1.6 Limitações e delimitação da pesquisa
É importante destacar que não há a pretensão de submeter esse trabalho de
concepção e teste de aplicativo móvel de modelagem e simulação a eventos
discretos sob o prisma de todos os aspectos abordados pelas normas NBR ISO/IEC
9126-1 (2003) e ISO/IEC 25010 (2011) ou qualquer outra ligada a entidades de
padrões e qualidades, como a, ISO/IEC 14598-5, 12119, 12207, 29119-2, 15504
(SPICE), IEEE 829 ou métodos ágeis como o DSDM, Extreme Programming ou
Scrum.
Por um lado, Sommerville (2011, p.449) em seu capítulo sobre garantia e
padrões de qualidade, argumenta que os engenheiros de software, algumas vezes,
consideram as normas e seus padrões como burocráticos e irrelevantes para a
atividade técnica de desenvolvimento de software. Para Pressman (2011, p.359)
qualidade de software pode ser definida como uma gestão de qualidade aplicada de
modo a criar um produto útil que forneça valor mensurável para aqueles que o
produzem e para aqueles que o utilizam. Por outro lado, Marím e Olalla (2011)
afirmam que a literatura sobre qualidade reconheceu o potencial da certificação ISO
para auxiliar empresas certificadas a obter os resultados desejados, permitindo-lhes
melhorias de qualidade.
Segundo a NBR ISO/IEC 9126-1 (2003) a avaliação de produtos de software
tem o objetivo de satisfazer as necessidades de qualidade de software, que é um
dos processos no ciclo de vida de desenvolvimento de software, ou seja, a qualidade
de software está diretamente ligada ao processo de desenvolvimento de software.
Contudo, pode-se afirmar que neste trabalho, foram observadas
características que tratam das funcionalidades e eficiências, estabelecidas pelas
normas NBR ISO/IEC 9126-1 e ISO/IEC 25010, e que serviram de referências para
a avaliação de um protótipo de aplicação para a área de estudo. Segundo ISO/IEC
25010 (2011) um modelo de qualidade deve determina quais características de
qualidade serão consideradas ao avaliar as propriedades de um produto de
software.
Igualmente nos trabalhos de Djouab e Bari (2016) e Fauzi et al. (2016),
apenas a norma 9126-1 foi utilizada como referência e adequações para seus
7
estudos sobre metodologias para avaliação de qualidade de software. Já em outro
exemplo, no trabalho de Alshayeb (2013) apenas a característica Manutenibilidade
foi considerada ao abordar o tema da instabilidade de softwares que podem causar
elevação de custos de manutenção.
Vale também destacar que apesar da norma 9126-1 de 2003 ter sido
substituída pela ISO/IEC 25010 em 2011, ainda persiste sendo muito referenciada
na literatura em questões ligadas a qualidade de software. As características que
tratam da funcionalidade e eficiência se equivalem nas duas normas. As
subcaracterísticas Completude Funcional, Correção Funcional, Adequação
Funcional, Comportamento em relação ao tempo (desempenho) da norma 25010
são equivalentes as subcaracterísticas Adequação, Acurácia e Comportamento em
relação ao tempo (desempenho) da norma 9126-1. Sendo assim, as nomenclaturas
adotadas neste trabalho para referenciar tais subcaracterísticas são: Adequação,
Acurácia e Desempenho.
Com relação ao aplicativo que será submetido a teste, trata-se de um
protótipo de simulador de eventos discretos, o Simuni9, com funcionalidades básicas
implementadas, tendo condições de propiciar um ambiente para que modelos
simples de simulação de sistemas de filas com um ou dois servidores sejam
modelados. Portanto, os resultados obtidos na aplicação dos testes de software
propostos neste estudo são restritos ao protótipo criado e submetido aos testes. No
entanto, outros aplicativos similares que venham a ser criados no ambiente dos
dispositivos móveis, também poderão ser submetidos aos mesmos testes propostos.
Ressalta-se ainda que o termo e tema deste trabalho “concepção” e que
envolve prototipação, não se refere a criação de um produto de software total e
completo abordando todas as fases de desenvolvimento prevista na engenharia de
software ou em normas e padrões relacionadas a software.
A palavra concepção empregada neste trabalho está em conformidade com a
fundamentação teórica apresentada na seção 2.3.2, denotada na frase de
Pressmann (2011, p.147) que na fase de concepção do projeto de software é
necessário levantar as principais características e funções que devem estar
presentes em um sistema.
8
Sobre prototipação, Summerville (2011, p.30) argumenta que a construção de
um protótipo permite demonstrar conceitos, experimentar opções, descobrir mais
sobre o problema, possíveis soluções e ainda pode ajudar na elicitação e validação
de requisitos de sistema.
9
2. Fundamentação teórica
Este capítulo contempla o referencial teórico necessário para o
desenvolvimento deste trabalho. A pesquisa baseou-se em livros, dissertações,
teses, e artigos científicos sobre os seguintes temas: conceito de softwares e
aplicativos para dispositivos móveis; qualidade e teste de software para dispositivos
móveis; modelagem e simulação computacional; sistemas de filas; etapas para a
criação de modelos de simulação; ferramentas de modelagem e simulação e
números pseudoaleatórios gerados a partir de distribuições de probabilidades
estatísticas.
2.1 Conceito de software
Software ou programa de computador é um conjunto de instruções ordenadas
logicamente que são entendidas e executadas pelo computador. Os softwares
possuem várias classificações, porém de uma forma mais simplista, pode-se
classifica-los basicamente em dois tipos principais (TANENBAUM, 2010):
Sistemas operacionais: são os softwares de base ou softwares básicos,
que controlam o funcionamento do computador nas suas operações
mais básicas e essenciais. O sistema operacional fornece aos
programas do usuário um modelo de computador mais simples, e lida
com o gerenciamento de recursos como processadores, memória
principal, discos, impressoras, teclado, mouse, monitor, interfaces de
rede e outros dispositivos de entrada e saída.
Softwares aplicativos ou simplesmente aplicativos: executam tarefas de
interesse do usuário, com ou sem sua intervenção ou interação, como
ocorre nos processadores de texto, planilhas eletrônicas, softwares
gráficos, entre outros.
Os softwares aplicativos são utilizados de várias formas, diretamente no
computador, por rede local, pelos dispositivos móveis, ou ainda pela internet, em
que nos últimos anos se viu estabelecer o conceito de Cloud Computing ou
computação as nuvens. Cloud Computing refere-se à utilização da capacidade de
armazenamento e processamento de computadores compartilhados por meio da
10
internet de forma transparente ao usuário, mas que permita sua utilização
(CAITHNESS, DRESCHER, e WALLOM, 2017).
2.2 Aplicativos para dispositivos móveis
No universo dos dispositivos móveis, os softwares aplicativos para essas
plataformas são comumente chamados de aplicativos móveis ou simplesmente
apps. Entre os sistemas operacionais mais utilizados, destaca-se o Android da
proprietária Google Inc, o mais popular entre todos com 87,6% do mercado; o
sistema iOS da Apple Inc e o Windows-Phone da Microsoft Corporation (IDC, 2016).
Já entre fabricantes de smartphones e tablets há mais diversificação. A
Samsung, por exemplo, lidera o mercado de vendas mundiais dos smartphones com
21,8%, seguido da Apple com 14,6%, Huawei 8%, os outros 57,6% são pulverizados
entre vários outros fabricantes (GARTNER, 2016).
Tais aplicativos são criados com preocupações adicionais para a engenharia
de software, por estarem inseridos em um contexto com tantos fabricantes
produzindo modelos variados, com tamanhos de telas diferentes, disponibilidades de
recursos variados como teclado, câmera, memória e capacidade de processamento
bem diferente entre as várias opções existentes no mercado. Na avaliação desses
produtos de software, muitas vezes os próprios fabricantes abrem a possibilidade de
que os mesmos sejam avaliados com a participação dos usuários, analisando
versões betas (versão para avaliação) ou mesmo a versão final, com divulgação dos
resultados e argumentações dessas avaliações em fóruns públicos de discussões
(RUIZ et al., 2017).
No trabalho de Joorabchi, Mesbah e Kruchten (2013) é apresentado uma
grounded theory com 12 desenvolvedores seniors de 9 empresas diferentes,
seguido de uma pesquisa semi-estruturada, com 188 entrevistados da comunidade
de desenvolvimento móvel, sendo o resultado uma visão geral dos desafios atuais
enfrentados pelos desenvolvedores na prática, como o desenvolvimento de
aplicativos em várias plataformas. Entre as dificuldades apontadas na pesquisa,
destaca-se, grandes variedades de modelos, falta de ferramentas robustas de
monitoramento para análises e testes, emuladores lentos ou que perdem muito das
características dos dispositivos móveis.
11
Outro fator que dificulta o processo de desenvolvimento e avaliação de
aplicativos para dispositivos móveis é o comportamento dos usuários, abordado
como com um novo paradigma, a engenharia de software orientada a mercados,
como pode ser visto na pesquisa de Lim et al. (2014) que investigou através de uma
survey com 4824 participantes, o comportamento diferente de usuários em 15
países no mundo, ao baixarem aplicativos das apps-stores, exemplificando, os
americanos têm uma tendência maior em baixar aplicativos para a área médica, os
usuários do Reino Unido e do Canadá são mais propensos a serem influenciados
pelo preço, usuários do Japão e Austrália tem menos chances de avaliar aplicativos.
Como visto, tais fatos acabam contribuindo para as dificuldades e desafios no
processo de desenvolvimento destes aplicativos e também nos processos de testes
de software dos mesmos.
2.3 Qualidade de software
A qualidade de software é um dos desafios e preocupações na área da
engenharia de software e está diretamente relacionada à qualidade do seu processo
de desenvolvimento. Essa é uma das premissas da norma 9126-1 (NBR ISO/IEC,
2003). Assim sendo, para se obter um software com maior qualidade, é necessário
que seu processo de desenvolvimento seja melhorado, com a adoção de
procedimentos, normas e padrões bem estabelecidos.
Existem entidades responsáveis pela normalização e padronização de
produtos e serviços de maneira geral visando a qualidade, como pode ser visto no
quadro 1. Em âmbito mundial a ISO (International Standardization Organization)
fundada em 1947, a IEC (International Electrotechnical Commission) fundada em
1906. No Brasil a representante oficial da ISO é a ABTN (Associação Brasileira de
Normas Técnicas, fundada em 1940 e membro fundadora da ISO (ABTN, 2017).
Marím e Olalla (2011) afirmam que a literatura sobre qualidade reconheceu o
potencial da certificação ISO 9000 para auxiliar empresas certificadas ISO a obter
resultados desejados, permitindo-lhes melhorias de qualidade.
12
Quadro 1: Exemplos de normas e padrões relacionadas a software
Norma Abordagem
ISO 14598 Avaliação de produto de software
ISO 9126-1 / 25010 Qualidade de produto de software
ISO 12119 / 25051 Testes e requisitos de qualidade de pacote de software
ISO/IEC 12207 Processos do ciclo de vida e desenvolvimento de software
ISO/IEC 15504 Avaliação do processo de desenvolvimento de software
ISO 1779 / 27000 Técnicas de segurança
ISO/IEC 20000 Gerenciamento de qualidade de serviços de TI
IEE 829 Padrão para documentação de teste de software
SEI CMMI / MPS-BR Maturidade e melhoria no desenvolvimento de software
ISO/IEC 29119-2 Modelo genérico para processos de testes de software
Fonte: Adaptado de ISO (2017), ABNT (2017), CMMI (2017) e SOFTEX (2017)
2.3.1 Normas de referência de qualidade de software ISO/IEC 9126-1 e 25010
As normas ISO/IEC 9126-1 e ISO/IEC 25010 abordam um conjunto de
características e subcaracterísticas que tratam o assunto da qualidade de software.
A norma 9126-1 é uma norma genérica muito referenciada na literatura e base para
outras normas mais específicas e recentes. É reconhecida como referência para a
aplicação de padrões de qualidade ao especificar e avaliar atributos do produto de
software, podendo ser usadas para avaliar e identificar requisitos funcionais e não-
funcionais para o desenvolvimento e teste de software (DJOUAB e BARI, 2016),
(FAUZI et al., 2016) e (NBR ISO/IEC 9126-1, 2003).
As características ligadas a funcionalidades e eficiências das normas 9126-1
e 25010, foram referências para este trabalho de concepção e testes de software
descritos e são apresentadas a seguir. O apêndice A apresenta todas as
características e subcaracterísticas dessas normas.
As características ligadas às funcionalidades abordam a capacidade do
produto de software de prover funções que atendam às necessidades explícitas e
implícitas, quando o software estiver sendo utilizado sob condições especificadas.
Algumas de suas subcaracterísticas são:
13
Adequação ou Completude é a capacidade do produto de software de
prover um conjunto apropriado de funções para tarefas e objetivos do
usuário especificados.
Acurácia ou Exatidão é capacidade do produto de software de prover,
com o grau de precisão necessário, resultados ou efeitos corretos ou
conforme acordados.
A característica Eficiência diz respeito a capacidade do produto de software
de apresentar desempenho apropriado, relativo à quantidade de recursos usados,
sob condições especificadas. Duas de suas subcaracterísticas são:
Comportamento em relação ao tempo (Desempenho): capacidade do
produto de software de fornecer tempos de resposta e de
processamento, além de taxas de transferência, apropriados, quando o
software executa suas funções, sob condições estabelecidas.
Utilização de recursos: capacidade do produto de software de usar tipos
e quantidades apropriados de recursos, quando o software executa
suas funções sob condições estabelecidas.
Como já afirmado na seção 1.6 as características que tratam da
funcionalidade e eficiência se equivalem nas duas normas, assim sendo, as
nomenclaturas adotadas neste trabalho para referenciar tais subcaracterísticas são:
Adequação, Acurácia e Desempenho.
2.3.2 Concepção e prototipação de software
Na engenharia de software, a especificação de software é o processo de
compreensão e definição dos serviços requisitados do sistema e identificação de
restrições relativas à operação e ao desenvolvimento do sistema. Essa parte do
processo pode envolver o desenvolvimento de um ou mais modelos de sistemas e
protótipos, os quais ajudam a entender o sistema a ser especificado
(SUMMERVILLE, 2011, p.24-25).
Na concepção do projeto de software devem ser levantadas as principais
características e funções que devem estar presentes em um sistema (PRESSMANN,
2011, p.147).
14
A prototipação, segundo Summerville (2011, p.30), é a construção de um
protótipo, que poderá ser a versão inicial de um produto de software, usado para
demonstrar conceitos, experimentar opções de projeto e descobrir mais sobre o
problema e possíveis soluções. Pode ser usada no processo de engenharia de
requisitos para ajudar na elicitação e validação de requisitos de sistema. Também
nos processos de projeto de sistema, para estudar soluções específicas do software,
como apoiar o projeto de interface de usuário.
2.4 Testes de softwares para dispositivos móveis
Teste de softwares para dispositivos móveis refere-se a testes manuais,
automáticos ou híbridos, quando ambos são utilizados. Nos testes híbridos é
adotada uma combinação entre ferramentas de testes, mas com muito envolvimento
manual nas operações (JOORABCHI, MESBAH, KRUCHTEN, 2013).
As ferramentas de testes de softwares são aplicativos que conduzem o
processo de testes de maneira automática após configurações e parametrizações
iniciais. Já os métodos de testes manuais são processos que averiguam de maneira
manual, sem ferramentas específicas, o funcionamento de alguns aspectos do
produto de software avaliado. Bourque e Fairley (2014) afirmam que teste de
software consiste na verificação do comportamento dinâmico de um programa
considerando um conjunto finito de casos de teste. Para Bastos et al. (2012, p. 31) o
objetivo principal do processo de teste é encontrar o maior número possível de
defeitos no software.
Segundo a literatura consultada, existem várias ferramentas adotadas para
testes de software em ambiente Android, conforme resumidas no quadro 2. Na
coluna um está o nome da ferramenta, a coluna dois informa sua aplicabilidade e a
coluna três destaca alguns dos trabalhos pesquisados que citam tais ferramentas.
No entanto, escolher e adotar ferramentas ou metodologias que tornem os
processos de testes automáticos, nesse ambiente dos dispositivos móveis, não é
uma tarefa simples e trivial, visto que a literatura demonstra que muitos
desenvolvedores ainda optam por testes manuais pela desconfiança ou ineficiência
das ferramentas de teste existentes. Tao e Gao (2016) afirmam que recentemente
um grande número de ferramentas de teste móvel foram desenvolvidas para
15
suportar automação de teste para mobile, como Appium, Robotium e Selendroid,
porém há limitações inerentes a todas as ferramentas, também pelo fato de haver
múltiplas plataformas para diversos dispositivos (Android, iPhone, Windows Phone,
entre outros), fazendo com que os engenheiros de testes necessitem conhecer
diferentes linguagens para escrever scripts de testes para plataformas diferentes.
Em outra argumentação, os autores afirmam que as ferramentas não fornecem uma
estrutura de automação unificada e há uma falta de confiança em adotar métodos de
teste para mobile para lidar com diversidades tão acentuadas.
Quadro 2: Ferramentas de teste de software para ambiente Android
Ferramentas de Teste de Software para Android
Ferramentas Aplicação e uso Artigos
Android Mock Testes JUnit na máquina virtual Dalvik do Android usando classes Android mocks.
Merwe (2012)
AppDoctor Usa a técnica de approximate execution para acelerar os testes e reduzir o esforço de diagnóstico.
Hu et al. (2014)
Appium
Framework moderno para automação de testes para aplicativos mobile multiplataformas gerando scrips em várias linguagens.
Tao e Gao (2016) e Gunasekaran e Bargavi (2015)
JpfAndroid Verificação se aplicativos são Android.
Liu, Xu, Cheung (2012)
JUnit Testa as unidades do sistema. Ferramenta que acompanha o Android.
Merwe (2012), Zaeem, Prasad, Khurshid (2014)
Monkey Executa teste aleatório com grande número de eventos aleatórios.
Hu et al. (2014), Jensen et al. (2013), Takala et al.(2011)
MonkeyRunner Realiza testes funcionais e que faz uso do framework JUnit.
Hu et al (2014), Jensen et al. (2013), Takala et al. (2011)
Robotium + JUnit
Simula interações do usuário com o aplicativo; utiliza o framework JUnit que já vem com o Android.
Tao e Gao (2016), Hu et al.(2014), Liu, Xu, Cheung (2012), Merwe
(2012), Takala et al.(2011), Zaeem, Prasad, Khurshid (2014)
Selenium e Selendroid
Framework para testes funcionais em aplicações web mobile.
Tao e Gao (2016)
TestDroid
Conduzir testes de interface do usuário via scripts em uma variedade de dispositivos usando o sistema Android.
Kaasila (2012)
Apesar das muitas ferramentas encontradas de testes automáticos de
softwares para dispositivos móveis, parece haver uma corrente na literatura
especializada consultada que, tais ferramentas são insuficientes ou ineficientes e o
16
teste manual ainda é prevalecente na maioria dos casos de testes adotados. A figura
1 resume a predileção de 95% por testes manuais, considerando que os testes
híbridos de 31,4%, ainda têm envolvimento manual (JOORABCHI, MESBAH,
KRUCHTEN, 2013).
Figura 1: Tipos de testes mais usados
Fonte: Adaptado de (JOORABCHI, MESBAH, KRUCHTEN, 2013)
Seja manualmente ou de forma automática, quando se tem preocupações
com a qualidade, o importante é ter conhecimento exato do que deve ser testado e,
nesse caso, deve-se conhecer bem a destinação do aplicativo. Pressman (2009,
pg.786) diz que a atividade de testes de software é um elemento crítico da garantia
de qualidade de software.
Um aplicativo para atuar na área da modelagem e simulação a eventos
discretos possui características específicas que devem ser testadas, como, ter a
capacidade de gerar números pseudoaleatórios com distribuições de probabilidades
estatísticas confiáveis, permitir a criação de modelos de simulação de sistema de
filas, animação da simulação, entre outras. Logo, é pouco provável que ferramentas
automáticas de testes possam suprir tais necessidades. Neste caso, uma
combinação de diferentes tipos de testes deverem ser adotadas.
2.5 Modelagem e simulação computacional
Segundo Law e Kelton (2000, p.1) em modelos simples pode-se usar métodos
matemáticos, como álgebra, cálculo ou probabilidade, para obter informações exatas
sobre questões de interesse. Isso é chamado de solução analítica. No entanto, para
sistemas complexos do mundo real, deve-se adotar a simulação por computador,
A
A – Automático
M – Manual
H – Híbrido
O - Outros
M H O
17
para avaliação dos dados coletados. Com a modelagem e simulação pode-se
estimar medidas de desempenho de um sistema modelado aproximando-se os
resultados simulados ao mundo real.
Moreira (2007, p.271) diz que simulação envolve o uso de computadores e a
construção de modelos aproximado da realidade e que possam ser operados
repetidas vezes para análise dos resultados.
Andrade (2009, p.14 e p.123) afirma que modelos de simulação procuram
representar sistemas do mundo real com o objetivo de permitir a geração e análise
de alternativas, antes da implantação definitiva de tais sistemas.
Softwares de modelagem e simulação são ferramentas que, por meio de
modelos lógico-matemáticos viabilizam experimentos que permitem aproximar a
realidade de processos e operações do mundo externo para dentro de laboratório de
pesquisa ou computadores. Prado (2009, p.19) define simulação como uma técnica
que utiliza modelos de simulação criados por programas de computador que
permitem imitar o funcionamento de um sistema real.
Vieira (2006), em seu trabalho de revisão sobre a aplicação de simulação
computacional, apresenta referências de autores que abordaram o tema desde a
década de 70, como Schriber (1974) descrevendo que simulação implica na
modelagem de um processo ou sistema, de tal forma que o modelo imite as
respostas do sistema real numa sucessão de eventos que ocorrem ao longo do
tempo. Em seguida, cita Shannon (1975) afirmando que simulação é quase sinônimo
de simulação computacional, na qual um modelo computacional é executado. Para
ele, a simulação computacional pode ser definida como um programa de
computador cujas variáveis apresentam o mesmo comportamento dinâmico e
estocástico do sistema real que representa.
Segundo Nance (1993) a simulação computacional pode ser classificada em
três categorias: simulação Monte Carlo, simulação contínua e simulação de eventos
discretos.
Para Falcão e Molinari (2016) a simulação computacional de Método Monte
Carlo, conhecida pala sigla MMC, é apresentada por qualquer método de uma
18
classe de métodos estatísticos que se baseiam em amostragens aleatórias massivas
para obter resultados numéricos, isto é, repetindo sucessivas simulações um
elevado número de vezes, para calcular probabilidades heuristicamente.
Andrade (2009, p.128) descreve a simulação de Monte Carlo como um
processo de operação de modelos estatísticos de modo a lidar experimentalmente
com variáveis descritas por funções probabilísticas. Para Chwif (1999), a simulação
Monte Carlo é aquela em que um problema, notadamente não probabilístico, é
solucionado através de um processo estocástico, resultante de eventos aleatórios.
A figura 2 resume os tipos de simulação trazidos por Law e Kelton (2000) e
em seguida uma descrição de cada tipo.
Figura 2: Diferentes tipos de simulação.
Fonte: Adaptado de Law e Kelton (2000)
estática, representa sistemas num momento particular ou quando o tempo
simplesmente não tem função, sendo simulação Monte Carlo um exemplo.
dinâmica, representa sistemas que mudam com o passar do tempo e
podem ser:
determinística, quando o conjunto de entradas e saídas não
contenham nenhum componente probabilístico;
estocástica, quando possuir valores que respeitam uma distribuição
estatística ou aleatória, podendo ser:
Contínua Eventos discretos
Determinística Estocástica
Dinâmica
Simulação
Estática
19
o contínua, quando as variáveis mudam ao longo do tempo de
simulação de maneira constante;
o eventos discretos, quando as variáveis se mantém estáticas
por um período de tempo e podem ser modificadas após a
ocorrência de algum evento.
Observa-se que diferentemente do método Monte Carlo, tanto a simulação
contínua como a simulação a eventos discretos, levam em conta o tempo para a
realização das simulações.
Em simulações contínuas, o estado do sistema muda continuamente em
função do tempo. Exemplificando, o crescimento da população mundial, a retirada
de líquidos de uma garrafa de forma ininterrupta, a variação de temperatura ao longo
do dia, o derretimento do gelo.
Em simulações a eventos discretos, o estado do sistema muda somente no
instante que ocorre um evento, para todos os demais instantes de tempo, nada
muda no sistema ou na parte analisada. Como exemplo, a chegada de um paciente
em um posto de atendimento.
Os sistemas de filas são exemplos de sistemas do mundo real que podem ser
simulados com a modelagem e simulação a eventos discretos, simulando as
chegadas e saídas de elementos no sistema, a formação das filas de espera e o
tempo de atendimento.
2.6 Sistemas de filas
O sistema de filas estuda as ocorrências e fenômenos encontrados em
sistemas em que a formação de filas é uma possibilidade a ser considerada,
utilizando tempos de chegadas e de atendimento para avaliação do funcionamento
geral e estimativa da formação ou não de filas no sistema. As filas podem ser
encontradas em ambientes de produção, transportes, comunicações e em qualquer
tipo de atendimento (PRADO, 1999).
20
O sistema de filas estuda as diversas formas de filas, que por meio de
modelos adequados pode-se representar diversos tipos filas (HILLIER e
LIEBERMAN, 2013).
Andrade (2009, p.104) trata o problema de congestionamento das filas,
exemplificando que, é caracterizado pela presença de clientes solicitando serviços
em posto de serviços e que, eventualmente, devem esperar até que o posto de
atendimento esteja disponível, como em um posto de atendimento ao público, um
setor de manutenção de equipamentos, operação em caixas de pagamento, entre
outros.
As figuras 3 e 4, ilustram a estrutura do sistema de filas com um e três canais
de serviços, na visão de Andrade (2009).
Figura 3: Estrutura do sistema de filas com um canal de serviço
Fonte: Adaptado de Andrade (2009)
Figura 4: Estrutura do sistema de filas com três canais de serviço
Fonte: Adaptado de Andrade (2009)
Ferro (2014) argumenta que o dimensionamento errado de um sistema de
atendimento pode gerar filas e apresenta vários autores que trazem contribuições
para esse tema, como no trabalho de Lange, Samoilovich e Rhee (2013), que
aplicaram a teoria das filas para estimar a taxa de chegada à estação de
21
atendimento de um setor em um aeroporto com o objetivo de dimensionar a
quantidade de atendentes disponíveis para garantir a qualidade do atendimento.
Lin e Chen (2012) desenvolveram um modelo baseado na teoria das filas com
o objetivo de avaliar um sistema de produção gerenciado por meio da ferramenta
Kanban.
Singer e Donoso (2008) utilizaram as técnicas da teoria das filas, para a
avaliação e o dimensionamento de um sistema de socorro por meio de ambulâncias,
no qual foram mapeadas as distribuições dos atendimentos utilizando um
levantamento histórico, em seguida foi possível avaliar a necessidade de compra de
novas ambulâncias.
Um conceito importante na teoria das filas é a disciplina de atendimento, que
determina qual regra será empregada para definir a ordem de atendimento dos
clientes na fila. Segundo Coelho, Dantas e Silva (2016), sinteticamente as regras de
definição das disciplinas de filas são:
FIFO - primeiro a entrar é o primeiro a sair. Arenales et al. (2007, p.438)
apresenta a mesma disciplina de atendimento sob a denominação FCFS -
primeiro a chegar é o primeiro a ser servido.
LIFO - último a chegar é o primeiro a sair;
PRI - atendimento por prioridade;
SIRO - atendimento aleatório, o atendimento aos clientes não segue nenhuma
regra;
A disciplina de filas LIFO é a mais comum de ser observada em sistemas de
manufatura onde os recursos são colocados, por exemplo, em pilhas, o último a ser
colocado pode ser o primeiro a sair (AKHAVIAN e BEHZADAN, 2014).
A aleatoriedade dos números em modelos de sistema de filas é outro
elemento importante a ser considerado, pois pode ser empregada para representar
tempos entre chegadas e tempos de atendimento em serviços, pois são elementos
muitas vezes de natureza aleatória e que necessitam da geração de números com
essa natureza para os sistemas de modelagem e simulação. Segundo Freitas (2001)
22
a simulação existente faz uso de distribuições de probabilidades como forma de
representar a multiplicidade de ocorrências de eventos aleatórios.
As seções 2.7 e 2.8 tratam as questões relacionadas a criação de modelos de
simulação, onde são abordados assuntos sobre etapas para a criação de modelos,
ferramentas de simulação e a questão da geração de números aleatórios segundo
uma distribuição de probabilidade estatística.
2.7 Etapas para a criação de modelos de simulação
Para criar modelos de simulação é necessário planejar o modelo tendo como
foco o sistema do mundo real que será simulado.
Os dados obtidos com os resultados da simulação devem refletir o melhor
possível os resultados do sistema do mundo real. Banks et al. (2010, p.12)
propuseram um conjunto de etapas para orientar a construção de modelos de
simulação, incluindo verificação e validação dos resultados. Tais etapas são
ilustradas na figura 5 e descritas em sequência.
Similar ao trabalho de Banks et al. (2010), Pereira e Chwif (2010) apresentam
um modelo para o processo de simulação com as etapas divididas em três fases,
concepção, implementação e análise, como pode ser visto na figura 6 e descritas em
sequência.
É importante destacar que nestes dois trabalhos apresentados, na etapa 5 do
modelo de Banks et al. (2010) e etapa 2.1 proposto por Pereira e Chwif (2010), a
construção do modelo computacional, não é possível sem a adoção de uma
ferramenta de modelagem e simulação capaz de executar tal tarefa.
A seção 2.8 aborda assuntos relacionados a ferramentas de modelagem e
simulação.
23
Figura 5: Etapas de um modelo de simulação
Fonte: Adaptado de Banks et al. (2010)
24
Etapas de cada fase do modelo de Banks et al. (2010):
1- Formulação de problema. Estudo sobre o sistema real a ser simulado.
2- Definição dos objetivos e planejamento geral. Indicam as questões a serem
respondidas pela simulação. Neste ponto, deve-se determinar se a simulação
é a metodologia apropriada para o problema conforme formulado e os
objetivos como afirmados, quais os custos e pessoas envolvidas no processo
e qual o tempo necessário para executar este trabalho.
3- Modelo conceitual. Construção do modelo conceitual para traduzir a lógica
obtida pelo levantamento das informações sobre o sistema.
4- Coleta de dados. Coleta do conjunto de dados que fará parte do modelo,
para que o mesmo seja posteriormente validado.
5- Conversão do modelo. Propõem a tradução do modelo conceitual para a
forma computacional, gerando assim um modelo operacional.
6- Verificação. Deverá ser verificado se a lógica do sistema está bem
representada pelo modelo computacional e se o modelo está funcionando
conforme a expectativa do programador.
7- Validação. Propõem a validação a fim de comparar as respostas do modelo
simulado com o real, e utilizar as discrepâncias encontradas e o
conhecimento adquirido para aperfeiçoar o modelo.
8- Delineamento experimental. Sugerem que seja definido como cada um dos
testes no modelo deve ser realizado, considerando parâmetros como tempo
de duração da simulação e número de replicações.
9- Execução do modelo e análise. Sugerem a execução de várias rodadas da
simulação para posterior análise.
10- Mais execuções. Esta etapa deve questionar a necessidade de mais
rodadas ou testes adicionais.
25
11- Documentação e relatórios. Propõem levantar a documentação e
relatórios sobre o modelo de simulação, tendo, na documentação, a finalidade
de descrever os processos utilizados na programação para que outros
analistas possam manipular o modelo ou construir outro similar
12- Implementação. Afirmam que o sucesso da fase de implementação
depende de uma boa execução dos passos anteriores, do envolvimento do
analista durante a construção e testes no modelo e, como consequência, se o
usuário compreende os resultados do modelo.
Figura 6: Fases do processo e simulação
Fonte: Pereira e Chwif (2010) - adaptado de Chwif e Medina (2007)
Etapas de cada fase do modelo de Pereira e Chwif (2010):
1-Concepção:
1.1- Objetivos e definição do sistema.
1.2- Formação do modelo abstrato;
1.3- Representação do modelo conceitual e dados de entrada;
2- Implementação:
2.1- Construção do modelo computacional;
2.2- Implementação do modelo;
2.3- Verificação e validação dos dados;
26
3- Análise:
3.1- Modelo operacional;
3.2- Experimentação do modelo;
3.3- Obtenção dos resultados experimentais;
3.4- Análise e redefinição para novas rodadas de simulação.
2.8 Ferramentas de modelagem e simulação computacional
As ferramentas de modelagem e simulação computacional são softwares que
permitem a criação de modelos de simulação através da manipulação de objetos
gráficos e configurações de elementos que permitam realizar simulações que
reflitam processos executados no mundo real. Possuem características próprias que
são discutidas em diversos trabalhos encontrados na literatura. Como na pesquisa
de Gupta (2014) que afirma que no mercado existe uma variedade de pacotes de
software de simulação a eventos discretos e discute como selecionar um software
de simulação mais adequado em função dessas características, inclusive apresenta
várias outras pesquisas nessa temática.
Outro exemplo é o trabalho de Tewoldeberhan, Verbraeck e Hlupic (2010) em
que foram apresentados 19 outros trabalhos ao longo dos anos que tratam o tema,
aos quais atribui como as mais relevantes e principais contribuições da literatura
sobre seleção de software de simulação e apresenta uma metodologia para apoiar
na decisão de escolha da ferramenta de simulação mais adequada sob os critérios
estabelecidos em sua pesquisa, por intermédio de um software de simulação a
eventos discretos.
O software Arena é um exemplo de ferramentas de modelagem e simulação
usada em várias áreas. Palominos, Quezada e Moncada (2009) adotaram essa
ferramenta para modelar um sistema a fim de investigar a flexibilidade de uso de
máquinas e sua capacidade de produção em uma indústria da confecção.
Sirathienchai, Sophatsathit e Dechawatanapaisal (2012) utilizaram a mesma
ferramenta em um modelo de simulação para investigar as diferenças de capacidade
e desempenho de pessoal iniciante e experiente para atuarem na área de teste de
software, comprovando que ter pessoas qualificadas nesta área é determinante para
a qualidade do processo.
27
2.8.1 Características dos softwares de modelagem e simulação
Na literatura encontram-se vários trabalhos sobre as características dos
softwares de simulação.
No trabalho de Banks e Gibson (1997), referência para vários trabalhos
posteriores, apresenta uma lista com 33 características divididas em 7 grupos à
serem consideradas na seleção de um software de simulação no meio corporativo.
Gupta (2014) apresenta alguns critérios para classificar softwares de
simulação, considerado como uma medida relativa de qualidade desses softwares
na perspectiva de grupos de critérios e não como um valor absoluto. Em seu
trabalho são definidas 14 características.
O quadro 3 agrupam as características definidas por cada autor apresentado.
Nos trabalhos pesquisados, muitas vezes os critérios de seleção são por
características mais objetivas e claras, como facilidade de uso, preço, popularidade
do software, facilidades estatísticas, entre outros. No trabalho de McClellan (2004),
por exemplo, a seleção do software de simulação Promodel para a realização de
seus experimentos se deu frente as seguintes características observadas pelo autor:
modelagem de início rápido com uma interface fácil de usar;
desenvolvimento com cenários "e se", de forma rápida, simples e sem
riscos;
importação e análise de dados com facilidade, podendo ser enviados
ao Microsoft® Excel™;
capacidade de realizar aleatoriedades e variabilidades nos modelos;
capacidade de importar mais de 20 tipos de distribuições estatísticas
ou gerar diretamente seus próprios dados;
Muitas das características levantadas na literatura sobre softwares de
modelagem e simulação podem ser qualificadas pela engenharia de software, como
requisitos funcionais ou não funcionais.
28
Os requisitos funcionais descrevem explicitamente serviços ou funções do
sistema, ou seja, exatamente quais ações ele executa ou disponibiliza ao usuário,
enquanto que os não funcionais, podem ser mais críticos que os funcionais e não
estão diretamente relacionados com os serviços oferecidos pelo sistema, mas
podem estar relacionados às propriedades emergentes do sistema (SOMMERVILLE,
2011).
Exemplos de requisitos funcionais:
Parametrização de objetos de simulação;
Composição dos modelos de simulação;
Geração de números aleatórios estatisticamente distribuídos;
Execução do modelo de simulação;
Animação do modelo de simulação;
Emissão de relatórios de simulação.
Exemplos de requisitos não funcionais:
Confiabilidade;
Tempo de resposta;
Segurança;
Eficiência;
Facilidade de uso.
29
Quadro 3: Características dos softwares de simulação
Gupta (2014) Banks e Gibson (1997)
Informações gerais;
Aspectos de codificação;
Compatibilidade de software;
Suporte ao usuário;
Recursos gerais;
Assistência à modelagem;
Aspectos visuais;
Eficiência;
Testabilidade;
Recursos financeiro e técnico;
Facilidades de experimentação;
Recursos estatísticos;
Capacidades de entrada e saída;
Recursos de análise e resultados.
Recurso de apontar o mouse;
Utilização de desenhos;
Importação de arquivos;
Exportação de arquivos; Sintaxe
compreensível; Controle interativo
de execução; Interface com
figuras; Recurso para análise de
dados de entrada.
Entrada
Possibilidade de modelagem
complexa; Velocidade;
Flexibilidade de execução;
Geração de valores aleatórios;
Reinicialização (reset);
Replicações independentes.
Processamento
Flexibilidade lógica. Programação
Relatórios padronizados;
Relatórios Customizados;
Geração de gráficos; Manutenção
de bancos de dados; Coleta do
resultado das operações
matemáticas; Medidas de
desempenho específica da
aplicação; Saída para arquivos.
Saída
Facilidade de uso; Facilidade de
aprendizado; Qualidade da
documentação; Recursos de
animação.
Ambiente
Estabilidade; História; Suporte. Fornecedor do
software
Aquisição de licença;
Atualizações; Treinamento e
suporte.
Custo
30
2.8.2 Números pseudoaleatórios estatisticamente distribuídos
A geração de números aleatórios segundo uma distribuição de probabilidade
é indispensável nos modelos de simulação, pode-se dizer que é uma das
funcionalidades mais críticas para um software de simulação. Através desses
números é possível, por exemplo, criar estimativas baseadas em eventos que
ocorrem ao longo de um período de tempo, portanto eventos discretos, com duração
ou comportamento que se pretende simular e que são obtidos por intermédio dessa
aleatoriedade numérica. Moreira (2011, p.286) argumenta que geradores de
números ao acaso, portanto aleatórios, são ferramentas ou sub-rotinas de
computador, por meio dos quais tais números podem ser gerados para uso na
simulação.
Na geração de números aleatórios usando recursos computacionais, esbarra-
se em limitações inerentes ao próprio hardware ou ao software, já que em geral os
computadores são determinísticos. Isso quer dizer que, o mesmo programa
executado mais de uma vez com todas as entradas idênticas irá produzir sempre as
mesmas saídas ou os mesmos resultados. Por essa razão, os números gerados por
computador recebem o nome de pseudoaleatórios, ou seja, a imprevisibilidade não é
conseguida sem o auxílio de fatores externos e não é algo que o computador
consiga produzir por si só. A aplicabilidade de números aleatórios gerados, também
chamadas de variáveis aleatórias, pode ser encontrada na literatura nos inúmeros
exemplos referentes ao tema, como se pode atestar no trabalho de Silva et al.
(2014) que afirma que a simulação computacional de qualquer fenômeno aleatório
envolve a geração de variáveis aleatórias com distribuições pré-definidas.
Uma vez que um modelo de distribuição de probabilidade tenha sido
escolhido, um algoritmo para geração da variável aleatória deve ser utilizado. Bakry
e Shatila (1988) afirmam que softwares para a geração de números aleatórios são
de grande importância para muitas aplicações científicas e de engenharia, como a
modelagem de sistema, simulação computacional, amostragem, análise numérica,
entre outros.
Smith (2016) apresenta em seu trabalho um exemplo de geração de números
aleatórios seguindo uma distribuição exponencial, com servidor único em um
ambiente de filas com uma população finita de clientes.
31
Cormen et al. (2009, p.116) argumentam que em muitos casos pode-se criar
algoritmos aplicando-se a aleatoriedade como ferramentas na geração de números
estatisticamente distribuídos para obtenção de análises probabilísticas.
Chwif e Medina (2010) apresentam algumas características de números
aleatórios gerados segundo algumas distribuições de probabilidades, por exemplo:
distribuição exponencial: relatam a grande variabilidade dos valores,
independência entre um valor e outro, muitos valores baixos e poucos
valores altos, utilizada para representar o tempo entre chegadas
sucessivas a um sistema ou tempo de atendimento;
distribuição triangular: quando se conhece ou se tem uma boa suspeita
sobre a moda, o menor e o maior valor que podem ocorrer;
distribuição normal: quando a probabilidade de ocorrência de valores
acima da média é a mesma que valores abaixo da média.
Uma aplicação que se dispõe a servir de ferramenta para a área da
modelagem e simulação a eventos discretos necessita de tal funcionalidade de
geração de números pseudoaleatórios eficiente, que sigam uma distribuição de
probabilidade estatística adequada.
Logo, são necessários testes sob os aspectos das características que tratam
das funcionalidades e eficiências previstas nas normas de qualidade ISO/IEC 9126-1
e 25010, à luz das subcaracterísticas de adequação, acurácia e desempenho,
permitindo-se assim que tais números sejam confiáveis e representem o melhor
possível, os eventos aleatórios coerentes que os modelos de simulação necessitam.
32
3. Materiais e métodos
Neste capítulo é apresentado como se buscou alcançar os objetivos
propostos, descrevendo a estrutura da pesquisa e os procedimentos metodológicos
empregados na busca dos resultados.
Inicialmente foi aplicada uma pesquisa exploratória, com o objetivo de
familiarizar-se com o problema de pesquisa em tudo que o tema implica e tornando-
o explícito (GIL, 2008).
Como a proposta deste trabalho envolve experimentos, como, avaliação de
ferramentas de modelagem e simulação, ferramentas de testes de software, criação
de protótipo, avaliação do ambiente de desenvolvimento e testes de aplicativos,
também uma pesquisa experimental foi aplicada, a fim de averiguar as
possibilidades que o tema envolve, como, validar ou invalidar a concepção e testes
de software na avaliação de um aplicativo. Dessa forma, foi necessário identificar,
planejar, executar e verificar os resultados obtidos em cada experimento realizado.
3.1 Materiais adotados na pesquisa
Os materiais adotados neste trabalho são:
ferramenta de teste de software Appium para experimentos em
ambiente Android;
ferramenta de teste de software Katalon para para experimentos em
ambiente Android;
software de emulação de Android Genymotion para experimentos em
diversos modelos e versões de sistemas Android;
software Input Analyzer para aferição e análise estatísticos;
software Arena para validar os resultados oriundos da execução dos
modelos de simulação experimentais;
versões do S.O. Android experimentados:
o 4.0 Ice Cream Sandwich;
33
o 4.1, 4.2 e 4.3 Jelly Bean;
o 4.4 Kitkat;
o 5.0 e 5.1 – Lollipop;
o 6.0.1 Marshmallow.
experimentos com IDE Android Studio para criação do protótipo de
simulador, o Simuni9;
dispositivo móveis experimentados:
o smartphone Samsung J7 com 16 GB de memória;
o smartphone LG K 10 com 16 GB de memória;
o smartphone Huawei Y320 4 GB de memória;
o tablet Positivo Ypy L700+ com 1 GB de memória;
computador equipado com processor Core i3 Intel, 4 MB de memória
com sistema Windows 10;
3.2 Etapas e procedimentos da pesquisa
O planejamento para o desenvolvimento deste trabalho é resumido na figura 7
e detalhado a seguir.
Inicialmente foi necessária uma pesquisa exploratória para levantar as
ferramentas de modelagem e simulação disponíveis e acessíveis ao ambiente
acadêmico, para que pudessem nortear as decisões sobre quais ferramentas
serviriam de base para a construção deste trabalho de concepção e testes de
software para avaliar um aplicativo específico para a área de estudos.
No ambiente dos computadores, várias ferramentas ocupam destaque na
literatura e também estão consolidadas no meio corporativo. O software Arena
serviu de referência tanto para análise do funcionamento destas ferramentas, como
também foi adotado para validar os modelos criados pelo protótipo proposto.
34
Figura 7: Etapas e procedimentos da pesquisa
35
Outros experimentos também foram necessários, como no aplicativo online
ClouDES, por ser uma solução mais recente e que mais se aproxima da realidade
dos dispositivos móveis, apesar de se notar problemas flagrantes de morosidade e
travamentos, ao ser operado por navegadores de Internet nos smartphones ou
tablets.
Foram analisadas as funcionalidades básicas e fundamentais desses dois
softwares, a luz de algumas das características trazidas por Banks e Gibson (1997)
e Gupta (2014), apresentadas na seção 2.8.1, para que se pudesse levantar os
requisitos essenciais inerentes a uma aplicação desse tipo, já apresentadas na
seção 2.8.2, que serviram de base para a definição dos processos de teste de
software deste trabalho e na construção do protótipo de simulador para atuar no
ambiente móvel e que pudesse executar simulações de sistemas de filas com um ou
dois servidores.
Como apresentado na seção introdutória deste capítulo, parte do método de
pesquisa deste trabalho envolveu a construção e utilização de um protótipo de
simulador para os experimentos, o Simuni9, desenvolvido para atuar na área da
modelagem e simulação a eventos discretos no universo dos dispositivos móveis na
plataforma Android.
O protótipo foi desenvolvido em linguagem Java e Xml por intermédio do
ambiente integrado de desenvolvimento (IDE) Android Studio, após experimentos
realizados em outros IDEs que são apresentados no apêndice B.
Inicialmente foram testados os IDEs Netbeans e três versões do Eclipse
conforme citados no apêndice B, por serem as duas ferramentas mais populares e
consolidadas para programação em Java e possuírem comunidades de apoio muito
amplas na web.
Posteriormente, foram realizados testes com o IDE Android Studio,
ferramenta oficial de desenvolvimento Android da Google Inc., proprietária do
sistema operacional e também do IDE Android Studio (ANDROID STUDIO, 2016).
Os testes realizados nos três IDEs selecionados se resumiu na instalação,
exploração, utilização e experimentação dos recursos essenciais para construção e
36
execução de aplicativos para Android, e em funcionalidades bem específicas e
necessárias para um software de modelagem e simulação computacional.
Foram necessárias pesquisas e instalação de recursos complementares
disponibilizados online pelos IDEs, que são as chamadas APIs - Application
Programming Interface - Interface de Programação de Aplicativos, na avaliação de
recursos extras como fragmentes, animação de objetos, entre outros e verificar se
realmente eram plenamente satisfatórios diante das necessidades das
funcionalidades idealizadas para o protótipo construído.
Na construção do protótipo, os principais algoritmos foram os implementados
nas funcionalidades mais críticas e específicas para uma aplicação de modelagem e
simulação a eventos discretos e de maior desafio também para os procedimentos de
testes de software deste trabalho. Tais algoritmos foram adaptados de Santos
(1999) e Chwif e Medina (2010) e são descritos a seguir e detalhados no apêndice
C. Os principais algoritmos são:
Gerador de números aleatórios com distribuição estatística
exponencial;
Gerador de números aleatórios com distribuição estatística normal;
Gerador de números aleatórios com distribuição estatística triangular;
Rotinas e consistências que permitem simular sistema de filas com
estimativa de:
o número de chegadas;
o número de atendimentos;
o formação e tamanho de filas;
o tempo de atendimento;
o tempo de espera em fila;
o ocupação dos recursos do sistema de filas;
37
o diversas replicações;
o tempo de simulação total;
Tais algoritmos formam o que pode ser considerado o cerne de uma
aplicação de modelagem e simulação a eventos discretos. Eles são a base das
funcionalidades que permite criar modelos de simulação a eventos discretos.
Conforme apresentado na seção 2.7, a construção de modelos de simulação
requer a observação de etapas bem definidas. A figura 8 ilustra e sintetiza todo esse
processo na formação dos modelos de simulação.
Para criar tais modelos é necessário planejar o modelo tendo como foco o
sistema do mundo real que será simulado. Essa é a fase de concepção do modelo.
Na fase de Implementação é necessário que a funcionalidade que permita a
criação de modelos de simulação esteja disponível no protótipo e que o mesmo
proveja condições práticas para que tais modelagens sejam implementadas.
Figura 8: Etapas para criação de modelos de simulação
Fonte: Adaptado de Banks et al. (2010) e Pereira e Chwif (2010)
Nas fases de Experimentação e Análise, diversos cenários, além de novas
parametrizações e replicações podem ser necessários, a fim de ajustar o modelo
criado para que se aproxime ao máximo do modelo real ou simular novas
perspectivas, situações hipotéticas ou reais.
38
Após a construção do protótipo, com as principais funcionalidades
implementadas, o passo seguinte foi um estudo de quais ferramentas automáticas
de teste de software adotar, já que vários trabalhos levantados na literatura
alertavam para dificuldades na adoção e limitações destas ferramentas, conforme
relatado nas seções 2.2 e 2.4.
Além das pesquisas, foram necessários experimentos com ferramentas de
teste para averiguar o potencial e o comportamento das mesmas frente a algumas
das funcionalidades implementadas no protótipo.
As ferramentas Appium, Katalon Studio, Selendroid e Robotium foram
experimentadas e optou-se, então pela ferramenta Appium por sua eficiência nos
testes realizados, além de razões adicionais como, capacidade de testar aplicativos
de várias plataformas, gerar scripts de testes em várias linguagens de programação,
ser open source, ou seja, de código aberto, e facilidades de uso (GUNASEKARAN e
BARGAVI, 2015).
Na sequência, em busca de se determinar um enredo claro para os
procedimentos de testes, foi necessário segmentar as funcionalidades da aplicação
que seriam submetidas aos testes.
Outro fator importante a se considerar é que algumas funcionalidades são
extremamente complexas e dificilmente um software automático de testes poderá
fazê-lo de maneira satisfatória e completa, pois dependem muito da observação,
experiência e sensibilidade humana, além de vários outros fatores subjetivos ou
tratados pela característica usabilidade prevista na norma ISO/IEC 9216-1 e 25010,
que não é pretensão deste trabalho avaliar.
As funcionalidades precisaram ser testadas de maneiras diferentes, seja
pelas dificuldades inerentes a cada processo ou pelas limitações e restrições que as
ferramentas de testes apresentaram.
Dessa forma, após uma análise das características de cada funcionalidade,
foi estabelecido um tipo de teste mais adequado para cada uma delas e que serão
detalhados no capítulo 4.
Os tipos de testes adotados foram:
39
- automático: por intermédio da ferramenta automática de testes Appium;
- manual: com a aplicação de critérios objetivos de avaliação;
- híbrido: com o apoio dos softwares Input Analyzer e Arena.
É importante enfatizar que inicialmente procurou-se concentrar os estudos e
priorizar a adoção do teste automático, na tentativa de realizar os procedimentos de
avaliação de maneira rápida, eficiente e definitiva em todas as funcionalidades do
protótipo, por intermédio de ferramentas automáticas de testes de softwares.
Na impossibilidade de adotar teste automático na avaliação de algumas
funcionalidades, o teste híbrido passou a ter prioridade na avaliação, analisando
cada funcionalidade e softwares de apoio aos testes.
Quando evidenciado a não viabilidade de avaliar alguma funcionalidade por
intermédio dos testes automáticos ou híbridos, a avaliação manual foi então
empregada.
Assim sendo, procurou-se adotar o tipo de teste que melhor pudesse avaliar
as funcionalidades e contribuir favoravelmente com os procedimentos de teste de
software deste trabalho.
40
4. Resultados
Neste capítulo serão apresentados os resultados referentes a concepção,
prototipação e testes de um aplicativo específico de modelagem e simulação a
eventos discretos no ambiente dos dispositivos móveis.
4.1 Concepção do protótipo Simuni9
A luz da concepção e prototipação apresentada na seção 2.3.2 e
características dos softwares de modelagem e simulação a eventos discretos
apresentadas na seção 2.8, a seguir são definidas as características das
funcionalidades que uma aplicação específica para atuar em dispositivos móveis
deve contemplar. A definição destas características está baseada nos trabalhos
pesquisados, experimentos realizados diretamente nas ferramentas de simulação e
consultas nos websites disponibilizados por alguns fabricantes ou desenvolvedores
de ferramentas de simulação Arena (2015), Cloudes (2016), Padilla et al. (2014)
entre outros.
As características funcionais definidas e implementadas no protótipo Simuni9
e que serão submetidas a teste são:
Painel com módulos de simulação parametrizáveis;
Configuração dos módulos de simulação;
Composição dos modelos de simulação;
Consistências mínimas para validação dos modelos;
Geração de números aleatórios estatisticamente distribuídos;
Execução do modelo de simulação;
Animação do modelo de simulação;
Emissão de relatórios coerentes com o modelo criado.
O protótipo Simuni9 permitiu avaliar os procedimentos de teste de software,
além de contribuir com a investigação sobre o comportamento das funcionalidades
essenciais para um simulador nesse ambiente, a fim de se confirmar a viabilidade de
um produto de software definitivo para a área em questão.
41
Na seção 4.2 são apresentados os procedimentos de teste de software para
avaliação do protótipo de simulador para modelagem e simulação a eventos
discretos. O protótipo que será submetido a testes é apresentado na seção a seguir.
4.1.1 Painel de objetos
O Painel de objetos, figura 9, é composto por módulos selecionáveis e
parametrizáveis de acordo com a necessidade do modelo de simulação pretendido.
Os objetos ou módulos de simulação são elementos configuráveis e utilizados
na construção de modelos de simulação e estão descritos no quadro 4.
A seleção destes elementos é obtida com um clique simples no objeto
desejado, que em seguida disponibiliza uma janela para que seja configurado.
A aplicação inicia dinamicamente a montagem do modelo de acordo com a
sequência das escolhas e configurações realizadas.
A não necessidade do recurso drag-and-drop (arrastar e soltar), comuns em
aplicativos desse tipo, mas dificultoso em dispositivos móveis, facilitam a criação dos
modelos de simulação.
Figura 9: Painel de objetos
42
Quadro 4: Descrição dos módulos de simulação
Módulo Função
Create Inicia um modelo de simulação trazendo especificações e características das entidades que chegam no sistema de filas.
Process Determinar quais os postos de serviços ou atendimentos.
Dispose Finaliza os modelos de simulação.
Decide Módulo utilizado para realizar operações condicionais.
Batch Permite criar agrupamento de entidades que chegam a um processo de atendimento.
Record Com esse recurso, pode-se registrar estatísticas de contagem e tempo no modelo.
Separate Desfaz o agrupamento realizado pelo módulo Batch ou replica uma mesma entidade para ser atendida simultaneamente por dois serviços diferentes.
Assign Mudança de algum valor ou configuração de uma variável ou atributo de entidade durante a execução da simulação.
4.1.2 Seleção e parametrização de objetos
Os módulos de simulação devem ser configurados assim que são
selecionados, possibilitando parametrizar as características pertinentes a cada
módulo, como pode ser visto figura 10.
Nesse exemplo é demonstrada a configuração do módulo Create,
adicionando os parâmetros nome do objeto como ‘Entrada’, distribuição
‘exponencial’, parâmetro de média igual a ‘2,5’.
Dependendo da distribuição de probabilidade escolhida, a quantidade de
parâmetros solicitada será diferente, sendo, média e desvio padrão para a
distribuição normal e valor mínimo, máximo e moda para a triangular.
43
Figura 10: Parametrização de objetos
4.1.3 Construção dos modelos de simulação
A composição dos modelos de simulação se dá dinamicamente, ou seja,
assim que cada módulo é selecionado e o processo de parametrização finalizado, o
módulo é inserido no modelo automaticamente pela aplicação.
A figura 11 ilustra uma sequência de seleção, configuração e formação do
modelo com os módulos inseridos da esquerda para a direita.
No exemplo apresentado, pode-se notar um modelo com um módulo de
entrada (Create), dois módulos de processo (Process) e um módulo de saída
(Dispose).
Figura 11: Modelo gerado dinamicamente
44
4.1.4 Números aleatórios confiáveis
Em modelos de simulação de sistemas de filas, a estimativa de ocorrências
de eventos nas chegadas ou atendimentos necessitam da geração de milhares de
números pseudoaleatórios confiáveis e que sigam uma distribuição de probabilidade
estatística. Uma aplicação de simulação precisa prover essa funcionalidade com
precisão para que a simulação seja confiável e o mais próximo possível da realidade
simulada.
Na aplicação em questão, a geração desses números fica a cargo de uma
funcionalidade introduzida nos módulos Create e Process, em que, assim que suas
parametrizações são concluídas, disparam a geração de dez mil números aleatórios
estatisticamente distribuídos que são atribuídos aos eventos durante a simulação.
A seção 4.4.3 apresenta procedimentos para avaliação dessa funcionalidade.
4.1.5 Animação do modelo de simulação
Essa funcionalidade apresenta uma animação, figura 12, que pretende ilustrar
a execução gradual da simulação do sistema de filas com seus vários eventos, como
as chagadas, a formação de filas, o atendimento realizado, na tentativa de aproximar
a simulação das ocorrências do mundo real.
Figura 12: Animação da simulação
45
4.1.6 Relatórios gerados após a simulação
Durante a execução da simulação, o comportamento do sistema simulado é
documentado numericamente de acordo com o surgimento das ocorrências dos
eventos presentes no modelo, como formação de filas, número de chegadas,
número de atendimentos, entre outros.
Ao final de todo o processo, um log (relatório) é gerado e armazenado e
poderá ser apresentado sempre que o ícone correspondente for acionado.
A figura 13 ilustra o relatório gerado após uma simulação realizada. Na seção
4.3.3.2 serão detalhados todos os dados provenientes de simulações realizadas no
protótipo e também simulações do mesmo modelo realizados no software Arena
para comparação dos resultados, a fim de contribuir na investigação para confirmar
a viabilidade de um aplicativo definitivo para modelagem e simulação a eventos
discretos no ambiente dos dispositivos móveis.
Figura 13: Resultados da simulação
46
4.2 Procedimentos para testes de aplicativo móvel
Essa seção descreve os procedimentos para teste de software para avaliar
um aplicativo para a área da modelagem e simulação a eventos discretos no
ambiente dos dispositivos móveis.
A figura 14 ilustra os elementos essenciais que integram a base de um
aplicativo para modelagem e simulação a eventos discretos e à quais tipos de testes
sevem ser submetidos. Os elementos que serão testados são:
Painel de objetos com os módulos que comporão os modelos de
simulação;
Processo de seleção e parametrização dos objetos, onde são
fornecidas as características de cada modulo;
Construção de modelos. Esse item diz respeito a como será realizada a
construção dos modelos de simulação;
Execução da simulação;
Comportamento estatístico dos números aleatórios gerados;
Animação dos modelos de simulação;
Relatórios com os dados de saída do modelo criado.
Na sequência é apresentado a descrição dos elementos da figura 13.
Figura 14: Visão geral dos testes
47
É possível perceber ainda na figura 14, o emprego de três categorias de
testes: automática; manual e híbrida. Para avaliar aplicações desse tipo, de acordo
com as pesquisas e experimentos realizados, não há como testá-las aplicando
apenas uma ferramenta automática de teste. Dessa forma, a ferramenta de teste foi
adotada onde foi possível o seu emprego e quando pode trazer algum benefício na
avaliação do aplicativo.
As atribuições para cada tipo de avaliação foram divididas da seguinte forma:
Avaliação Automática: seleção; parametrização dos objetos; execução
da simulação. Para realização destes testes será utilizado a ferramenta
de testes Appium, que poderá gerar scripts de testes para que o
mesmo seja replicado quantas vezes for necessário.
Avaliação Manual: painel de objetos de modelagem; construção dos
modelos; animação dos modelos. Para análise dessas funcionalidades
será utilizado apenas procedimentos manuais.
Avaliação Híbrida: execução da simulação; números aleatórios
confiáveis; relatórios coerentes. Além de procedimentos manuais é
necessário também o emprego de ferramentas que executam
funcionalidades similares ao aplicativo avaliado, para que possam
realizar uma análise e comparação dos resultados da simulação. O
aplicativo Input Analyzer e o Arena são adotados para validarem os
resultados.
A figura 15 ilustra os procedimentos de testes adotados para cada tipo de
teste. As três primeiras partes da figura, diz respeito a procedimentos para
realização do teste automático. A quarta e quinta parte da figura diz respeito a
procedimentos aplicados nos testes híbrido e manual. Ressalta-se que após o teste
automático, é possível realizar tanto o teste manual na sequência como o teste
híbrido, sendo assim, os passos 4 e 5 apresentados na figura 15 podem ser
invertidos sem qualquer prejuízo para os testes.
As seções 4.2.1, 4.2.2 e 4.2.3 detalham estes procedimentos separadamente.
48
Figura 15: Visão geral de cada fase dos testes
49
4.2.1 Teste automático – preparação do cenário de testes
Para os testes das funcionalidades, seleção, parametrização dos objetos e
execução da simulação, é aplicado o teste automático. São necessários os
seguintes itens: um computador com sistema operacional Windows ou Linux
instalados; um dispositivo móvel (smartphone ou tablet) para realização dos testes
conectado por cabo USB ou por emulador AVD (Android Virtual Device); ter o
aplicativo Appium instalado no computador.
Assim que a ferramenta de teste Appium é iniciada no computador, o
chamado servidor de testes deverá ser acionado, conforme ilustra a figura 16.
O servidor Appium, além de iniciar o aplicativo que será testado, irá
intermediar e registrar as ações executadas no aplicativo para que um script de teste
seja criado e posteriormente adotado por uma aplicação que irá tornar o processo de
teste automático.
Assim que todas as funcionalidades desejadas do aplicativo tiverem sido
executadas, o programador do teste poderá capturar o script de teste gerado pelo
Appium e aplicá-lo em uma aplicação Java, que conduzirá automaticamente todos
os procedimentos registrados pelo Appium, quantas vezes forem necessárias.
Figura 16: Tela do servidor Appium
A seção 4.3.1 descreve a aplicação do teste automático e seus resultados.
50
4.2.2 Teste manual
As funcionalidades painel de objetos de modelagem, construção dos modelos
de simulação e animação dos modelos, que dependem de análise crítica do
observador e do testador, são exemplos de casos em que a presença humana é
indispensável e são apresentadas nas seções subsequentes.
O painel de objetos de modelagem, por exemplo, deve ser observado e
avaliado por alguns parâmetros bem específicos e outros mais subjetivos, que
normalmente são avaliados pela característica de usabilidade.
Os específicos são: quantidade de objetos disponíveis no painel é
suficiente; quanto ao tamanho dos objetos; formato; cor; entre outros.
Os subjetivos são: o painel está em posição de fácil acesso; há
dificuldade em configurar cada objeto; a distribuição dos elementos é
coerente; entre outros.
O quadro 5, traz os parâmetros de avaliação que podem ser adotados ao
avaliar as características de cada item ou funcionalidade do aplicativo que careça de
uma avaliação manual e observação humana mais direta.
Dessa forma, se propõe que estes elementos sejam testados também
levando em conta o tempo gasto na composição e execução de um modelo simples,
contrapondo o mesmo modelo a uma ferramenta similar, como o Arena, ClouDES,
entre outros, mesmo sendo em plataformas diferentes.
Vale destacar que não é pretensão deste trabalho classificar melhores ou
piores, pois o tempo na construção e execução do modelo não é suficiente para tal,
mas para o testador, poderá servir como parâmetros para avaliação dos itens do
aplicativo de forma geral. Neste caso, a experiência do testador com os softwares
envolvidos também deve ser considerada, além de necessária.
51
Quadro 5: Características objetivas que devem ser observadas
Item Avaliado
Avaliação Manual
Critérios Alinhamento com as
normas ISO/IEC 9126 e 25010
Painel de
objetos de
modelagem
Quantidade de objetos disponíveis no painel;
Tamanho dos objetos;
Formato;
Cores adotadas.
Adequação
Construção
dos modelos
de simulação
Necessidade de clicar e arrastar objetos;
Como inserir cada objeto ao modelo;
A sequência do modelo condiz com o modelo real;
O tempo de construção ou execução são satisfatórios.
Adequação
Desempenho
Animação dos
modelos de
simulação
Quantidade de elementos gráficos;
Tamanho dos elementos;
Movimentação dos elementos é sincronizado com a evolução da simulação;
Adequação
Desempenho
A seção 4.3.2 descreve a aplicação do teste manual e os resultados lançados
em um quadro similar ao apresentado os resultados da avaliação manual.
52
4.2.3 Teste Híbrido
Na avaliação híbrida são utilizadas ferramentas para auxiliarem nos testes em
conjunto com procedimentos manuais.
Esta seção descreve como três importantes funcionalidades do aplicativo
serão testadas. São elas: a geração de números pseudoaleatórios estatisticamente
distribuídos; a execução da simulação; emissão dos relatórios com os resultados da
simulação realizada.
Testes dos números pseudoaleatórios gerados
Para os testes dos números pseudoaleatórios, será necessário o uso da
ferramenta de análise de dados Input Analyzer, que deverá receber os dados
provenientes da aplicação testada e determinará, através da adoção de métodos
estatísticos, a confiabilidade ou não dos dados gerados pela aplicação.
A ferramenta Input Analyzer oferece opção de receber amostras provenientes
de fontes externas, no caso a aplicação que gerou tais números, e através de uma
ação rápida e prática, realiza a análise estatística da amostra, inclusive com a
geração de gráficos ilustrativos, apresentando inclusive informações sobre a
aderência estatísticas. Dessa forma, pode-se comprovar se a fonte de dados
geradora dos números é confiável para executar tal funcionalidade.
Teste da execução da simulação e análise dos relatórios gerados
As funcionalidades de execução da simulação e geração de relatórios da
simulação, inicialmente podem ser acionadas pela aplicação do teste automático
permitindo que o modelo de simulação seja executado automaticamente, porém
testes de eficiência são necessários e ficam a cargo do teste híbrido.
A execução da simulação e os relatórios são os produtos finais da simulação
e os que trazem informações quanto ao correto funcionamento tanto do modelo
criado quando do aplicativo avaliado. As execuções dessas funcionalidades poderão
ser realizadas diretamente na aplicação em testes ou pelo servidor de testes Appium
utilizado nos testes automáticos, para que os dados de saída sejam gerados.
Após o termino da execução da simulação e emissão do relatório da
simulação, será necessário a utilização da ferramenta Arena ou qualquer outra em
53
que possa ser criado um modelo de simulação similar ao criado na aplicação
testada.
Os dados de ambos os relatórios, produtos da simulação devem ser
comparados e analisados se há similaridade entre as informações e se podem ser
considerados compatíveis estatisticamente.
Assim sendo, se faz necessários executar várias vezes o mesmo modelo em
ambos os simuladores, aplicado rigorosamente o mesmo cenário. Propõe-se que
seja realizado uma simulação de duração mínima de 8 horas e 10.000 replicações,
para aferir a similaridade dos dados gerados pela ferramenta testada.
Os seguintes itens comuns a ambos os relatórios devem ser analisados:
1. Quantidade de entidades geradas;
2. Quantidade de entidades atendidas;
3. Número de médio de entidades em fila;
4. Tempo médio de entidades em fila;
5. Percentual de ocupação do sistema;
6. Tempo de execução da simulação.
Outro quesito de análise importante, porém não determinante para a exatidão
dos resultados, é com relação ao tempo total de processamento da simulação e
deve ser observado e posteriormente comparado entre os modelos executados.
Uma outra recomendação é que diferentes cenários sejam modelados, com
variações de valores e outras distribuições de probabilidades.
A seção 4.3.3 descreve a aplicação do teste híbrido e seus resultados em três
cenários de modelagens de simulação diferentes.
No apêndice B é apresentado os resultados dos experimentos para definição
do IDE adequado para desenvolvimento do protótipo.
Os detalhes sobre os algoritmos adotados no protótipo para a geração destes
números são abordados no apêndice C.
54
4.3 Aplicação dos testes de software e análise dos resultados
A partir desta seção é apresento o detalhamento da aplicação dos
procedimentos de testes software na avaliação das funcionalidades do protótipo
Simuni9.
Como apresentado no início deste capítulo, os procedimentos de testes são
segmentados em três avaliações, a automática, a manual e a híbrida. As seções
4.3.1, 4.3.2 e 4.3.3 mostram a aplicação de cada uma delas.
A ordem para aplicação dos testes é determinada pela sequência natural de
execução do aplicativo em teste, assim sendo, como a execução inicial do aplicativo
se dará pela ferramenta Appium, então, inicia-se pelo teste automático, também
devido ao fato de que as outras avaliações necessitam que o aplicativo esteja
rodando. Na sequência dos testes, tanto o teste manual, como o híbrido poderão ser
realizados.
Também é importante destacar que na elaboração e na aplicação dos
procedimentos de teste para avaliação das funcionalidades do protótipo, observou-
se as diretrizes determinadas pelas características de funcionalidade e eficiência e
suas subcaracterísticas Adequação, Acurácia e Desempenho, previstas nas normas
ISO/IEC 9126-1 e 25010, exposta na seção 2.3.1.
4.3.1 Aplicação da avaliação automática das funcionalidades seleção,
parametrização dos objetos e execução da simulação.
Assim que o servidor Appium é iniciado, conforme apresentado na seção
4.2.1, em seguida, uma seção deverá ser iniciada no servidor de teste para que o
mesmo possa interceptar as requisições enviadas ao dispositivo móvel ou ao
emulador que serão utilizados para operacionalizar o aplicativo testado.
A figura 17 ilustra as configurações necessárias para que a nova seção seja
iniciada no servidor de teste.
55
Figura 17: Tela de configuração de seção no Appium
Os dados fornecidos ao servidor de testes são:
1- Endereço IP do host (endereço de rede) da máquina onde o dispositivo móvel está conectado via USB ou instanciado por um emulador.
2- O número da porta de comunicação necessário em conexões desse tipo.
3- Fornecer o código de configuração para que o servidor possa iniciar o aplicativo que será testado no dispositivo móvel.
Após as configurações realizadas, a seção poderá ser iniciada. A figura 18
apresenta a seção criada.
O aplicativo que será testado é carregado no dispositivo e em seguida
também é mostrado no painel de monitoramento do Appium.
A partir deste ponto, o aplicativo em teste poderá ser operado tanto pelo
painel do Appium ou diretamente pelo dispositivo.
1
2
3
56
Figura 18: Tela de acompanhamento do teste do Appium
As ações realizadas são registradas pela ferramenta de testes, gerando
scripts dessas ações. Posteriormente estes scripts podem ser aproveitados para que
os mesmos procedimentos registrados sejam exatamente reproduzidos em uma
aplicação de testes específica, quantas vezes se fizer necessário.
Na primeira coluna da figura 18, pode-se ver o aplicativo que está sendo
testado e o acionamento do botão Create em destaque na cor azul.
Na segunda coluna, encontra-se parte do código fonte do aplicativo, com um
destaque em uma das linhas do código em cor azul claro, correspondente ao objeto
clicado.
A terceira coluna traz informações resgatadas do objeto clicado que podem
ser úteis para corrigir eventuais falhas da funcionalidade, mostrando o ponto exato
em que o aplicativo está sendo analisado e outras características mais técnicas que
auxiliarão o programador em caso de erros.
Todo o processo de teste automático realizados pelo Appium está baseado
em registrar as ações executadas pelo testador e registrá-las em logs que serão
transformadas em scripts para alguma linguagem de programação e os dados
gerados poderão ser ajustados e consistidos pelo programador de testes, para
57
compor uma sequência de testes totalmente automáticos e reproduzi-los quantas
vezes forem necessários.
A figura 19 ilustra a utilização destes scripts gerados a partir do Appium e
utilizados em uma aplicação Java no Android Studio. Dessa forma, o teste pode ser
manipulado, passando a ser totalmente automático.
Figura 19: Tela de utilização dos scripts em uma aplicação Java
Com os scripts de testes gerados a partir da ferramenta de testes Appium,
pôde-se facilmente utilizá-lo em uma aplicação Java utilizando-se do Android Studio
e em então replicar o teste de maneira automática e acompanhar os lançamentos
dinamicamente no próprio dispositivo utilizado ou na versão emulada do Android.
A figura 20 ilustra a execução com sucesso do teste automático ao ser
acionado o botão play do Android Studio. Nela é demonstrada a abertura e a
operação automática do protótipo Simuni9.
58
Figura 20: Ilustração da execução automática do teste de software
59
Discussão dos resultados do teste automático
A execução do script de teste seguiu exatamente todos os passos
anteriormente realizados através da ferramenta Appium de forma automática, rápida
e sem erros.
Assim que o protótipo é aberto, inicia-se a seleção e configuração dos objetos
programados no script de testes, tudo de forma automática.
Enquadramento das funcionalidades aos quesitos de avaliação Adequação e
Desempenho, pois o conjunto apropriado de funções disponibilizadas pelo protótipo
foi adequado às necessidades da aplicação e executados normalmente sem
qualquer tipo de morosidade ou falhas, pelo contrário, foram executados
perfeitamente e em um ótimo tempo de resposta.
No entanto, observa-se que os testes executados foram em funcionalidades
meramente de entrada de dados, seleção ou acionamentos da execução, ou seja,
mais uma validação da interface do usuário ou teste de repetição.
Apesar do fato de que é possível programar dados para que sejam
consistidos durante o processo de teste automático, nem sempre isso é possível.
Como comparar 10.000 números aleatórios se foram corretamente gerados segundo
uma distribuição de probabilidade estatística? Como determinar qual o número
médio de pessoas em fila em um modelo de simulação, sem um cálculo analítico
implementado ou um outro modelo de referência para aferir os resultados?
As funcionalidades mais crônicas não podem ser testadas desta forma devido
à superficialidade da ferramenta de teste frente às complexidades inerentes a
aplicativos desse tipo.
60
4.3.2 Aplicação da avaliação manual das funcionalidades painel de objetos,
construção dos modelos e animação da simulação
O procedimento de teste manual iniciou-se observando o comportamento da
aplicação em teste como um todo, levando em conta as características de avaliação
apresentadas na seção 4.2.2.
A tela inicial do protótipo é apresentada pela Figura 21, onde é possível
observar um painel de objetos disponíveis para seleção por touch-screen e posterior
parametrização do elemento.
O protótipo é composto basicamente por quatro telas principais, as chamadas
fragments, separando o processo de modelagem, da seguinte forma:
Escolha dos objetos e parametrização
Configurações adicionais
Modelo automaticamente criado em função das escolhas
Resultados com relatórios da simulação
Figura 21: Protótipo de simulador SIMUNI9
61
A Figura 22 ilustra o comportamento do aplicativo quando um elemento é
selecionado no painel de objetos. Rapidamente é possível parametrizar o elemento,
definindo suas propriedades que afetarão o comportamento do modelo de
simulação.
Figura 22: Parametrização dos objetos
O protótipo implementa um recurso chamado fragments. Este recurso
possibilita criar e deslizar páginas de tela para os lados.
A Figura 23 ilustra esse comportamento e a formação instantânea do modelo
de simulação, baseado nas escolhas e parametrização dos objetos.
O recurso fragments comportou-se de forma adequada, sem qualquer tipo de
morosidade ou travamentos. Sua operação se mostrou muito ágil na manipulação
dos objetos pequenos e trocas entre telas. Ações bem comuns aos dispositivos
móveis.
62
Figura 23: Modelo gerado dinamicamente
O protótipo criado pôde executar as funções elementares de seleção de
objetos, parametrização, execução conforme as especificações de requisitos
funcionais que aplicação exige.
Outro comportamento importante observado é o fato do recurso por touch-
screen ter se mostrado mais prático na manipulação de objetos pequenos em forma
de ícones do que o recurso drag-and-drop, logo, procurou-se criar alternativas para
minimizar a dependência do recurso de clicar e arrastar, beneficiando assim a
facilidade de operação deste quesito ao optar-se pela criação de modelos de
simulação dinamicamente, ou seja, na medida em que os objetos são selecionados
e parametrizados, o modelo é criado em seguida pela própria aplicação, ficando a
critério do modelador fazer seus ajustes manualmente com a técnica de drag-and-
drop.
O quadro 6 sintetiza os resultados referente a aplicação da avaliação manual, a
luz das características objetivas propostas na seção 4.2.2.
Basicamente os testes manuais fazem o que não é possível ser realizado por
uma ferramenta de teste, seja ela automática ou não.
Os itens avaliados dependem da sensibilidade, experiência e do julgamento
humano. Mesmo em questões mais objetivas, como quantidade de objetos de
simulação, velocidade da animação da simulação, entre outros, não podem ser
medidos simplesmente por um valor absoluto. Pode-se dizer que é compreensível a
predileção por testes manuais, apontadas na seção 2.4, pelas dificuldades também
enfrentadas nos experimentos realizados neste trabalho.
63
Quadro 6: Avaliação manual das características do protótipo
Item Avaliado
Avaliação Manual
Critérios Resultados Alinhamento com as
normas ISO/IEC 9126 e 25010
Painel de
objetos de
modelagem
Quantidade de objetos disponíveis no painel
Tamanho dos objetos
Formato
Cores adotadas
8 objetos gráficos Bem visíveis em formato de ícones Variações geométricas simples Linhas amarelas com fundo cinza
Adequação
Construção dos
modelos de
simulação
Necessidade de clicar e arrastar objetos
Como inserir cada objeto individualmente ao modelo
A sequência do modelo condiz com o modelo real
O tempo de construção ou execução são satisfatórios.
Não. Uso de clique simples São adicionados automaticamente
assim que são configurados
Não avaliado Modelos básicos criados com
poucos cliques e tempo de execução inferior a dois segundos.
Adequação
Desempenho
Animação dos
modelos de
simulação
Quantidade de elementos gráficos
Tamanho dos elementos
Movimentação dos elementos é sincronizado com a evolução da simulação
6 elementos gráficos que se movimentam
Bem visível e que permite fazer distinção entre objetos em formato de pessoas
Não. Velocidade única não demonstra sincronicidade.
Adequação
Desempenho
64
Discussão dos resultados do teste manual
As funcionalidades avaliadas manualmente necessitam da sensibilidade e
experiência humana e dificilmente uma ferramenta automática de testes seria capaz
de realizar tais avaliações.
A funcionalidade Painel de objetos de modelagem pode-se afirmar que, se
enquadra positivamente ao quesito de Adequação prevista nas normas de
referência, pois provê condições para a criação do modelo de simulação. Acurácia e
Desempenho não se aplicam neste caso.
A funcionalidade Construção dos modelos de simulação pode-se afirmar que
se enquadra parcialmente aos quesitos de Adequação e Desempenho, visto que
trouxe facilidades e rapidez na construção do modelo, porém a alteração do modelo
e o comportamento em modelos maiores ou mais complexos não puderam ser
avaliados.
A funcionalidade Animação do modelo de simulação, apesar de ilustrar a
formação das filas, não se pode afirmar que se enquadra ao quesito de Adequação
ou Desempenho, visto que a movimentação dos objetos não possui sincronismo
com a execução da simulação.
65
4.3.3 Aplicação da avaliação híbrida das funcionalidades geração de números
aleatórios, execução do modelo e relatórios gerados
Para avaliação das funcionalidades geração de números pseudoaleatórios e
execução e geração de relatórios com resultados da simulação, foi necessário a
aplicação de testes híbridos, envolvendo operações manuais e softwares de apoio
para auxiliarem nos testes. A aplicação e os resultados são apresentados nas
seções 4.3.3.1 e 4.3.3.2.
Os softwares que auxiliaram nos processos de testes foram o Input Analyzer
para análise estatística dos resultados e o Arena para comparações e validação dos
modelos de simulação criados.
4.3.3.1 Avaliação da geração dos números pseudoaleatórios estatisticamente
distribuídos
Os procedimentos para a realização deste teste são:
1. Configuração dos módulos Create ou Process no aplicativo testado.
Estes módulos, após configurados acionam a geração de 10.000
números aleatórios. Os dados são armazenados nos arquivos
chegadas.txt e atendimento.txt com apenas 67,36 KB cada um e
gravados na memória do dispositivo móvel;
2. Estando no Input Analyzer importar um dos arquivos criados na opção
Data File / Data Existing, com um cabo USB;
3. Acionar a opção Fit All da ferramenta para verificar os resultados
obtidos e o gráfico gerado;
4. Analisar os dados gerados, que informarão a qual distribuição de
probabilidade estatística os dados são aderentes.
5. Repita a operação para o segundo arquivo a ser testado;
Após os procedimentos descritos acima, o protótipo realiza a geração de
10.000 números aleatórios segundo a distribuição de probabilidade configurada nos
objetos Create ou Process, podendo ser, exponencial, normal ou triangular.
66
A tabela 1 ilustra uma amostra dos 10.000 números aleatórios gerados pelo
protótipo. As três últimas colunas na tabela apresentam uma sequência dos dez
primeiros números gerados em cada uma das distribuições adotadas, a exponencial,
normal e triangular nos testes realizados.
Em todos os casos os números foram gerados e armazenados em arquivos
do tipo texto com tempo de execução total inferior a 1 segundo para cada uma das
distribuições envolvidas nos testes.
Tabela 1: Amostra dos números pseudoaleatórios gerados
Ferramenta geradora DISTRIBUIÇÃO DE PROBABILIDADE
Exponencial Normal Triangular
Protótipo Simuni9
1,7327
1,9525
0,1150
1,9022
2,0382
4,7807
3,2634
3,3237
3,0396
1,7327
“
“
“
2,2117
6,6162
6,3038
5,1007
3,4694
4,8730
7,7522
0,6566
4,7993
2,2117
“
“
“
5,4596
6,6162
6,3038
5,1007
3,4694
4,8730
7,7522
0,6566
4,7993
5,4596
“
“
“
Em seguida apresentam-se os resultados obtidos nos relatórios de análise
desses números realizados pela opção Fit All da ferramenta Input Analyzer, pelo
qual se pôde comprovar a aderência estatística na aleatoriedade dos números
segundo cada distribuição proposta e a similaridade dessa funcionalidade da
aplicação com a mesma funcionalidade da ferramenta Input Analyzer.
As figuras 24, 25 e 26 a seguir ilustram o comportamento dos números em
cada uma das distribuições de probabilidades adotadas nos experimentos e serão
explicadas na sequência.
67
Figura 24: Comportamento dos números com distribuição Exponencial
Figura 25: Comportamento dos números com distribuição Normal
Figura 26: Comportamento dos números com distribuição Triangular
A tabela 2 apresenta os valores dos parâmetros utilizados para a geração dos
números pseudoaleatórios e o p-value calculado em cada experimento obtidos pela
ferramenta de análise do Input Analyzer, pelo qual se pode averiguar a aderência de
cada distribuição geradas nos experimentos por intermédio do teste Qui-quadrado
que fornece o valor calculado do p-value, que é definido como a probabilidade de se
68
observar um valor da estatística de teste maior ou igual ao encontrado. O teste de
aderência Qui-quadrado testa a validade ou não da hipótese de aderência, sendo,
H0 = hipótese nula, ou seja, o modelo é adequado para representar a distribuição da
população e H1 = hipótese alternativa, o modelo não é adequado para representar a
distribuição população. Assim sendo, o p-value >=0,10 indica evidência fraca ou
inexistente contra a hipótese de aderência (CHWIF e MEDINA, 2010).
Os parâmetros utilizados em cada tipo de distribuição para a geração dos
números nos experimentos foram, média = 2 para a distribuição exponencial, média
5 e desvio padrão 2 para a distribuição normal e valor mínimo = 2 com moda = 5 e
valor máximo = 8 para a distribuição triangular.
Tabela 2: Comparativo do p-value em cada experimento
Distribuição Valor do p-value p-value >= 0,10 Parâmetros
Exponencial 0,372 Sim Media=2
Normal 0,241 Sim Média=5 Desvio
Padrão=2
Triangular 0,211 Sim Min=2, Max=8,
Moda=5
Os resultados apontam para números com distribuição exponencial no
experimento um, ilustrada pela figura 24, distribuição normal no experimento dois,
ilustrada na figura 25 e triangular no experimento três, ilustrada pela figura 26,
confirmando então que todos passaram no teste de aderência estatística.
Com relação ao processo de execução para gerar 10.000 números aleatórios
em cada experimento, vale destacar que o tempo médio de execução da aplicação
Simuni9, foi abaixo de um segundo, o que pode ser considerado rápido o suficiente
para aplicações a que se propõe o aplicativo, logo, pode-se afirmar que tal
funcionalidade testada, também se enquadra aos quesitos de adequação,
desempenho e acurácia, pois o conjunto apropriado de funções disponibilizadas pelo
69
protótipo foi executado perfeitamente, em velocidade aceitável, portanto com bom
desempenho das funções e exatidão nos dados.
4.3.3.2 Teste da execução da simulação e análise dos relatórios gerados
Para poder testar e analisar a execução da simulação e os dados
apresentados no relatório emitido pelo protótipo, modelos com três cenários distintos
foram criados, tanto no Arena quanto no protótipo Simuni9.
Cenário 1 – O intervalo entre chegadas de entidades a um posto de
atendimento segue uma distribuição de probabilidade exponencial na ordem de 2
minutos. O ritmo de atendimento dessas entidades no posto de serviços segue
também uma distribuição exponencial, com média de 3 minutos. Uma simulação
com duração de 8 horas, com 10.000 replicações devem ser realizadas.
Cenário 2 – O intervalo entre chegadas de entidades a um posto de
atendimento segue uma distribuição de probabilidade exponencial na ordem de 4
minutos. O ritmo de atendimento dessas entidades no posto de serviços segue uma
distribuição de probabilidade normal, com os parâmetros, média e desvio padrão de
5 e 2 minutos respectivamente. Uma simulação com duração de 8 horas, com
10.000 replicações devem ser realizadas.
Cenário 3 – O intervalo entre chegadas de entidades a um posto de
atendimento segue uma distribuição de probabilidade exponencial na ordem de 2,5
minutos. O ritmo de atendimento dessas entidades no posto de serviços segue uma
distribuição de probabilidade triangular, com os parâmetros, mínimo, máximo e
moda, de 1, 8 e 5 minutos respectivamente. Uma simulação com duração de 8
horas, com 10.000 replicações devem ser realizadas.
Os resultados referentes a simulação no Arena e no Simuni9 são
apresentados na tabela 3, conforme os itens comparativos da simulação
apresentados na seção 4.2.3.
70
Tabela 3: Comparativo de resultados de simulação ente o Arena e o Simuni9
Itens da simulação a analisar
Cenário 1 (10.000 replicações)
Cenário 2 (10.000 replicações)
Cenário 3 (10.000 replicações)
Arena Simuni9 Arena Simuni9 Arena Simuni9
Entidades de entrada 241,51 240,96 120,96 120,92 193,02 192,22
Entidades atendidas 159,58 158,80 93,83 94,03 102,15 101,84
Número médio em fila 41,02 41,0 13,82 13,51 45,22 44,77
Tempo médio em fila 80,71m 81,67m 53,74m 53,64m 111,46m 111,8m
% ocupação do sistema
99,2% 99,8% 98,3% 99,1% 99,8% 99,9%
Tempo de execução 9,0m 4,8s 11,20m 4,9s 10,59m 5,0s
Na avaliação da execução do modelo de simulação, observa-se grande
similaridade nos valores apresentados. No entanto, é importante destacar que o
número de replicações interfere na proximidade dos resultados entre os softwares
comparados e principalmente com relação ao modelo conceitual e real. Quanto
maior o número de replicações, maior será a aproximação entre os resultados.
Deve-se destacar a rapidez de execução da simulação no protótipo frente ao
Arena, como pode ser atestada no item tempo de execução na última linha da tabela
3. Os tempos de execução da simulação no Arena ficaram entre 9 e 11,20 minutos.
Já no protótipo os tempos ficaram em apenas 5 segundos.
As figuras 27 e 28 ilustram os modelos criados no Arena e no Simuni9, para
que a simulação fosse realizada e os dados de saída coletados dos relatórios de
cada aplicação. As figuras 29 e 30 ilustram os relatórios gerados por cada aplicativo
e que foram sintetizados na tabela 3. Os dados de ambas as figuras são referentes
ao cenário 2.
71
Modelagem no Arena
Figura 27: Modelagem no Arena
Modelagem noSimuni9
Figura 28: Modelagem no Simuni9
Resultados dos relatórios do Arena
Figura 29: Resultados da simulação no Arena
72
Resultados dos relatórios do Simuni9
Figura 30: Resultados da simulação no Simuni9
Discussão dos resultados do teste híbrido
Na avaliação da execução do modelo de simulação, observa-se grande
similaridade na maioria dos valores apresentados, com destaque na rapidez de
execução do protótipo frente ao Arena. Pode-se então concluir que, há um
alinhamento com as características Adequação, Acurácia e Desempenho previstas
nas normas de referências.
Apesar dos resultados apresentados serem matematicamente próximos,
pode-se aplicar ainda um teste estatístico mais preciso, como o teste-t para
comprovar a similaridade estatística dos resultados. Para auxiliar a eventuais testes
estatísticos, pode-se observar no relatório do protótipo, o cálculo do desvio padrão
para o item número do tamanho médio da fila, que é um importante indicador na
simulação.
73
5. Conclusão e trabalhos futuros
Neste capítulo são apresentadas a conclusão sobre este trabalho de pesquisa
e indicação para trabalhos futuros.
5.1 Conclusão
A presente dissertação teve como objetivo maior, a concepção e teste de
aplicativos para dispositivos móveis de modelagem e simulação a eventos discretos,
a partir do estudo das características essenciais e inerentes a estas ferramentas.
Pode-se afirmar que as características essenciais de tais ferramentas foram
levantadas com êxito, o que possibilitou a prototipação de um simulador e aplicação
de testes de software no ambiente móvel para a área em questão, tendo como
resultados tanto o protótipo como os procedimentos de teste de softwares
estabelecidos e aplicados positivamente, conforme apresentados no capítulo 4.
A aplicação dos procedimentos de teste de software automático expôs as
dificuldades preconizadas pela literatura sobre a utilização de ferramentas
automáticas de teste de software e a predileção por testes manuais e híbridos no
ambiente dos dispositivos móveis. Realmente a tarefa de testes usando ferramentas
de testes, ainda carece de muita intervenção manual e em muitos casos, apenas
testes manuais são possíveis.
Foi possível atestar que grande parte das funcionalidades do protótipo
puderam se enquadrar positivamente às características de Funcionalidade e
Eficiência e em suas subcaracterísticas Adequação, Acurácia e Desempenho,
previstas nas normas de referência adotadas neste estudo, ao avaliar o protótipo.
Pode-se afirmar também que, o objetivo específico de avaliar a viabilidade de
um aplicativo definitivo para a área da modelagem e simulação a eventos discretos
no ambiente dos dispositivos móveis, foi alcançado e se confirmou positivamente,
visto que os resultados dos experimentos e dos testes realizados nas simulações
foram executados de forma completa, correta e com desempenho comprovado,
evidenciando que é realmente viável a construção de um simulador para eventos
discretos eficiente nesse ambiente.
74
5.2 Trabalhos futuros
Como continuidade às pesquisas iniciadas neste trabalho visando uma maior
contribuição com uma ferramenta mais robusta e definitiva para a área da
modelagem e simulação a eventos discretos no ambiente móvel, pode-se ampliar as
investigações em duas frentes, no desenvolvimento e na implementação de outros
tipos de testes.
No desenvolvimento, a criação de um aplicativo definitivo para dispositivos
móveis, a partir do protótipo concebido nesse trabalho, melhorando as
funcionalidade e limitações existentes, como melhorias na animação, maior
detalhamento dos relatórios estatísticos da simulação, ampliação dos módulos de
simulação.
No processo de teste, a implementação de novos tipos de testes como testes
de usabilidade e performance podem ser considerados como uma complementação
pertinente para os estudos iniciados neste trabalho. Assim como testes e
experimentos em ambiente didático visando comparar os resultados do protótipo
frente ao Arena, a fim de explorar limitações e propor melhorias e mais
funcionalidades ao Simuni9.
Outras ferramentas automáticas de testes que venham a surgir poderão ser
experimentadas em substituição ou somadas a ferramenta Appium adotada neste
trabalho, a fim de averiguar se algumas das funcionalidades mais específicas
implementadas no protótipo serão avaliadas com maior rapidez e eficiência.
Por fim, a adequação do aplicativo para outras plataformas móveis como
iPhone ou Windows-Phone também pode-se considerar como mais uma
contribuição para a área da modelagem e simulação a eventos discretos.
75
Referências
ABNT. Associação Brasileira de Normas Técnicas. Disponível em: <http://www.abnt.org.br/contato> Acesso em: jul, 2017.
AKHAVIAN, R.; BEHZADAN, A. H. Evaluation of queuing systems for knowledgebased simulation of construction processes. Automation in Construction, Volume 47, November 2014, Pages 37-49. Disponível em: <http://www.sciencedirect.com/science/article/pii/S0926580514001587> Acesso: nov, 2014.
ALSHAYEB, M. On the relationship of class stability and maintainability. Journal IET Software, IEEE, vol. 7, no. 6, pp. 339-347, 2013.
ANDRADE, E. L. Introdução à pesquisa operacional, 4.ed. Rio de Janeiro, 2009.
ANDROID STUDIO, O IDE oficial do Android. Disponível em: <https://developer.android.com/studio/index.html> Acesso: nov, 2016.
ARENA, ROCKWELL. Arena simulation software. Disponível em: <http://www.rockwellautomation.com/rockwellsoftware/simulation.page> Acesso: out, 2015.
ARENALES, M.; ARMENTANO, V.; MORABITO, R.; YANASSE, H. Pesquisa Operacional. Rio de Janeiro, 2007.
BANKS, J.; CARSON, J. S.; NELSON, B. L.; NICOL, D. M. Discrete-Event System Simulation. Prentice Hall, 5. ed, 2010.
BANKS, J.; GIBSON, R. R. Selecting Simulation Software. IIE Solutions, 29(5): 30-32, 1997.
BASTOS, A.; RIOS, E.; CRISTALLI, R.; MOREIRA, T. Base de conhecimento em teste de software. 3. ed. São Paulo, 2012.
BOURQUE, P.; FAIRLEY, R. E. Guide to the Software Engineering Body of Knowledge, Version 3.0, IEEE Computer Society, 2013.
CAITHNESS, N.; DRESCHER, M.; WALLOM, D. Can functional characteristics usefully define the cloud computing landscape and is the current reference model correct? Journal of Cloud Computing, v. 6, n. 1, p. 10, jun. 2017.
CHWIF, L. Redução de modelos de simulação de eventos discretos na sua concepção. Tese (Doutorado em Engenharia) – Universidade de São Paulo, São Paulo, 1999.
CHWIF, L.; MEDINA, A. C. Modelagem e simulação de eventos discretos: teoria e prática. 3. ed. São Paulo, 2010.
76
CLOUDES, Build and play with simulations. Disponível em: http://test.cloudes.me. Acesso: out, 2016. CMMI INSTITUTE, Build Capability. Deliver Results. Disponível em: < http://cmmiinstitute.com/>. Acesso ago., 2017.
COELHO, C. J.; DANTAS, M. J. P.; SILVA, L. C. Aplicação da teoria de filas e
simulação em sistemas de produção com ênfase na teoria das restrições. XIX Simpósio de Administração da Produção, Logística e Operações Internacionais SIMPOI, São Paulo, 2016.
CORMEN, T. H.; LEISERSON, C. E.; RIVEST, R. L.; STEIN, C. Introduction to algorithms. 3. ed. Massachusetts Institute of Technology, 2009.
DANTAS, V. L.L.; MARINHO, F. G.; COSTA, A. L.; ANDRADE, R. M. C.. Testing Requirements for Mobile Applications. In Proceedings of the 24th International Symposium on Computer and Information Sciences - Guzelyurt: IEEE, p. 555-560, 2009.
DJOUAB, R.; BARI, M. An ISO 9126 Based Quality Model for the e-Learning Systems. International Journal of Information and Education Technology. 6. 370-375. 10.7763/IJIET.V6.716, 2016.
FALCÃO, G. B. N.; MOLINARI, R. Histórico, estado e perspectiva da tecnologia da compuatação quântica. Revista UNILUS Ensino e Pesquisa. Santos, São Paulo, 2016.
FAUZI, N. A. A.; HASSAN, R.; SHAH, Z. A.; ZAKARIA, Z. Extraction of Non-Functional Requirements in Reviewing Requirements Specification Document. International Journal of Software Engineering and Technology, 02(2) 20-26, 2016.
FERRO, R. Proposta de um método para melhoria de sistemas de produção baseada na simulação de eventos discretos e manufatura enxuta. Dissertação (Mestrado em Engenharia de Produção) - Universidade Metodista de Piracicaba, 2014.
GARTNER, newsroom, Top 10 Worldwide Mobile Phone Vendors Increased Sales in Second Quarter of 2016. Disponível em: http://www.gartner.com/newsroom/id/3415117>. Acesso: ago, 2017.
GIL. A. C. Como elaborar projetos de pesquisa. 4 ed. São paulo, 2008.
GUNASEKARAN, S.; BARGAVI, V. Survey on Automation Testing Tools for Mobile Applications. International Journal of Advanced Engineering Research and Science (IJAERS), n. 11, p. 36–41, 2015.
GUPTA , A., How to Select A Simulation Software, International Journal of
Engineering Research and Development, Volume 10, Issue 3, PP.35-41, 2014.
HILLIER, F. S.; LIEBERMAN, G. J. Introdução à pesquisa operacional. 9. ed. Rio de Janeiro, 2013.
77
HU, G., YUAN X., TANG, Y., YANG, J. Efficiently, effectively detecting mobile app bugs with AppDoctor. In: Proceedings of the Ninth European Conference on Computer Systems. ACM, p. 18, 2014.
IDC, Analyze the Future, Smartphone OS market share. Disponível em: http://www.idc.com/prodserv/smartphone-os-market-share.jsp. Acesso: set, 2016.
IEEE SECTRUM, The Top Programming Languages. Disponível em: <http://spectrum.ieee.org/static/interactive-the-top-programming-languages> Acesso: out, 2014.
ISO International Organization for Standardization. Disponível em: <https://www.iso.org> Acesso: ago, 2017.
ISO/IEC 25010:2011. Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - System and software quality models, 2011. Disponível em: <https://www.iso.org/standard/35733.html> Acesso: ago, 2017.
JENSEN, C.; S.; PRASAD, M. R.; MOLLER, A. Automated testing with targeted event sequence generation. In: Proceedings of the 2013 International Symposium on Software Testing and Analysis. ACM, p. 67-77, 2013.
JOORABCHI, M. E.; MESBAH, A.; KRUCHTEN, P. Real Challenges in Mobile App Development. 2013 ACM / IEEE International Symposium on Empirical Software Engineering and Measurement, p. 15–24, 2013.
JOSHI, P.; NIVANGUNE, A.; KUMAR, R.; KUMAR, S.; RAMESH, R.; PANI, S.; CHESUM, A. A. Understanding the Challenges in Mobile Computation Offloading to Cloud through Experimentation. 2nd ACM International Conference on Mobile Software Engineering and Systems, 2015.
KAASILA, J.; Ferreira, D.; Kostakos, V.; Ojala, T. (2012) Testdroid: automated remote UI testing on Android. In: Proceedings of the 11th International Conference on Mobile and Ubiquitous Multimedia. ACM, p. 28, 2012.
LANGE, R.; SAMOILOVICH, I.; RHEE, B.V.D. Virtual queuing at airport security lanes. European journal of operational research. vol. 225. 2013.
LAW, A.M.; KELTON, W.D. Simulation modeling and analysis, third ed. McGraw-Hill, New York, 2000.
LIM, S. L.; BENTLEY, P. J.; KANAKAM, N.; ISHIKAWA, F.; HONIDEN, S.I. Investigating Country Differences in Mobile App User Behavior and Challenges for Software Engineering. IEEE Transactions on Software Engineering, vol. 41, no. 1, pp. 40-64, v. 41, n. 1, p. 40–64, 2014.
LIN, F.J.; CHEN, Y.M. A simulation model with synchronization manufacturing stations. Management Decision. vol. 50, 7, 2012.
78
LIU, C. H.; LU, C. Y.; CHENG, S. J.; CHANG, K. Y.; HSIAO, Y. C.; CHU, W. M. Capture-Replay Testing for Android Applications. International Symposium on Computer, Consumer and Control, Taichung, pp. 1129-1132, 2014.
MARÍN, L. M.; OLALLA, M. C. R.ISO 9000:2000 certification and business results, International Journal of Quality & Reliability Management, Vol. 28 Iss 6 pp. 649 – 661, 2011.
MCCLELLAN, J.J. The benefit of using simulation to improve the implementation of lean manufacturing case study: quick changeovers to allow level loading of the assembly line. Dissertação (Mestrado), Brigham Young University, 2004.
MERWE, V. D. H.; MERWE, V. D. B.; VISSER, W. Verifying android applications using Java PathFinder. SIGSOFT Software Engineering Notes, ACM, v. 37, n. 6, p. 1-5, 2012.
MOREIRA, D. A.; Pesquisa Operacional: Curso introdutório. 2. ed. São Paulo, 2011.
NANCE, R. E. A history of discrete event simulation programming languages, In: Proceedings of the Second ACM SIGPLAN History of Programming Languages Conferences, Cambridge, MA, 28(3), pp. 149-175, 1993.
NBR ISO/IEC 9126-1. Engenharia de software - Qualidade de produto, Rio de Janeiro, 2003.
NIELSEN. Smartphones: so many apps, so much time. Media and entertainment. Disponível em: <http://www.nielsen.com/us/en/insights/news/2014/smartphones-so-many-apps--so-much-time.html> Acesso: nov, 2016.
PROVERBS, D.G. ; SANDANAYAKE, Y.G. A systematic modelling and simulation approach for JIT performance optimization. Robotics and Computer-Integrated Manufacturing, vol 24, Issue 6, pg. 735-743, ISSN 0736-5845 24, 735–743, 2008.
OLIVEIRA, S. D.; SAMPAIO, P. G.V. Estudo de modelagem e simulação de filas num supermercado associado à análise de cenários. XXXIII Encontro Nacional de Engenharia de Produção. Salvador, BA, Brasil, 08 a 11 de outubro de 2013.
PADILLA, J. J.; DIALLO S. Y.; BARRACO, A.; KAVAK, H.; LYNCH, C. J. Cloud-based simulators, Winter simulation conference. n. 2012, p. 3630–3639, 2014.
PALOMINOS, P.; QUEZADA, L.; MONCADA, G. Modeling the response capability of a production system. International Journal of Production Economics, vol 122, Issue 1, pg. 458-468, ISSN 0925-5273 2009.
PEREIRA, W. I.; CHWIF L. Especificação do modelo conceitual em simulação de eventos discretos: aplicação em um caso real. XXX Encontro nacional de engenharia de produção – ENEGEP. São Paulo, 2010.
79
PRADO, D. Teoria das filas e da simulação.3. ed. Belo Horizonte, 1999.
PRESSMAN, R. S. Engenharia de Software: Uma Abordagem Profissional. 7. ed. Amgh, São Paulo, 2011.
PRESSMAN, R. S. Engenharia de Software. 3. ed.Makron Books, São Paulo, 2009.
RUIZ, I.J.M.; NAGAPPAN, M.; ADAMS, M.; BERGER, T.; DIENST, S.; HASSAN, A. E. Examining the Rating System Used in Mobile-app Stores. IN IEEE SOFTWARE, v. 33, n. 6, p. 86-92, nov.-dec, 2016.
SANTOS, M. P. Introdução à simulação discreta. Departamento de Matemática e Estatística, Universidade do Rio de Janeiro, 1999.
SCHRIBER, T.J., Simulation Using GPSS, Wiley, NY,1974.
SHANNON, R. E., Systems Simulation: The Art Science. Prentice-Hall, Englewood Cliffs, 1975.
SILVA, R. O. B.; CAPELA, J. M. V.; CAPELA, M. V. Estudo de Distribuições de Probabilidade: Simulação e Aplicação. Proceeding Series of the Brazilian Society of Applied and Computational Mathematics, vol. 2, N. 1, 2014.
SINGER, M. e DONOSO, P. 2008. Assenssing an ambulance service with queuing theory. Computer & Operation Research. vol. 35, 2008.
SIRATHIENCHAI, J.; SOPHATSATHIT, P.; DECHAWATANAPAISAL, D. Simulation-Based Evaluation for the Impact of Personnel Capability on Software Testing Performance. Journal of Software Engineering and Applications, v. 2012, n. August, p. 545–559, 2012.
SOFTEX, MpsBR. Melhoria do Processo de Software Brasileiro. Disponível em: <http://www.softex.br/mpsbr/>. Acesso: ago., 2017.
SOMMERVILLE, I. Engenharia de software. 9. ed. Pearson Prentice Hall, São Paulo, 2011.
STATISTA, THE STATISTICS PORTAL. Number of apps available in leading app stores as of march 2017. Disponível em: <https://www.statista.com/statistics/276623/number-of-apps-available-in-leading-app-stores/> Acesso: jul, 2017.
TAKALA, T.; KATARA, M.; HARTY, J. (2011) “Experiences of system-level modelbased GUI testing of an Android application”. In: Software Testing, Verification and Validation (ICST) IEEE Fourth International Conference on. IEEE, p. 377386, 2011.
TANENBAUM, A. S. Sistemas operacionais modernos. 3. ed. Prentice Hal, São Paulo, 2010.
TAO, C.; GAO, J. Building a Model-Based GUI Test Automation. International Journal of Software Engineering and Knowledge Engineering. v. 26, p. 1605–1615, 2016.
80
TEWOLDEBERHAN, T. W.; VERBRAECK, A.; HLUPIC, V. Implementing a discrete-event simulation software selection methodology for supporting decision making at Accenture. Journal of the Operational Research Society. 61, 1446 --1458, 2010.
VIEIRA, G. E. Uma revisão sobre a aplicação de simulação computacional em processos industriais. XIII SIMPEP – Bauru, SP, 06 a 08 de novembro de 2006.
ZAEEM, R. N.; PRASAD, M. R.; KHURSHID, S.Automated Generation of Oracles for Testing User-Interaction Features of Mobile Apps. In: Software Testing, Verification and Validation (ICST), IEEE Seventh International Conference on. IEEE, p.183-192, 2014.
81
APÊNDICE A – Detalhamento das normas ISO/IEC 9126-1 e ISO/IEC 25010
Figura 31: Características e subcaracterísticas da norma ISO/IEC 9126-1
Fonte: Adaptado de NBR ISO/IEC 9126-1 (2003)
82
A figura 31 apresenta todas as características e subcaracterísticas previstas
na norma ISO/IEC 9126 que serão detalhadas a seguir (ISO/IEC 9126, 2003).
Funcionalidade: Esta característica aborda a capacidade do produto de
software de prover funções que atendam às necessidades explícitas e
implícitas, quando o software estiver sendo utilizado sob condições
especificadas. Suas subcaracterísticas são:
Adequação: capacidade do produto de software de prover um conjunto
apropriado de funções para tarefas e objetivos do usuário
especificados.
Acurácia: capacidade do produto de software de prover, com o grau de
precisão necessário, resultados ou efeitos corretos ou conforme
acordados.
Interoperabilidade: capacidade do produto de software de interagir com
um ou mais sistemas especificados.
Segurança de acesso: capacidade do produto de software de proteger
informações e dados, de forma que pessoas ou sistemas não
autorizados não possam lê-los nem modificá-los e que não seja
negado o acesso às pessoas ou sistemas autorizados.
Conformidade: capacidade do produto de software de estar de acordo
com normas, convenções ou regulamentações previstas em leis e
prescrições similares relacionadas à funcionalidade.
Confiabilidade: capacidade do produto de software de manter um nível de
desempenho especificado, quando usado em condições especificadas.
Suas subcaracterísticas são:
Maturidade: capacidade do produto de software de evitar falhas
decorrentes de defeitos no software.
Tolerância a falhas: capacidade do produto de software de manter um
nível de desempenho especificado em casos de defeitos no software
ou de violação de sua interface especificada.
Recuperabilidade: capacidade do produto de software de restabelecer
seu nível de desempenho especificado e recuperar os dados
diretamente afetados no caso de uma falha.
83
Conformidade: capacidade do produto de software de estar de acordo
com normas, convenções ou regulamentações relacionadas à
confiabilidade.
Eficiência: capacidade do produto de software de apresentar desempenho
apropriado, relativo à quantidade de recursos usados, sob condições
especificadas. Suas subcaracterísticas são:
Comportamento em relação ao tempo: capacidade do produto de
software de fornecer tempos de resposta e de processamento, além de
taxas de transferência, apropriados, quando o software executa suas
funções, sob condições estabelecidas.
Utilização de recursos: capacidade do produto de software de usar tipos
e quantidades apropriados de recursos, quando o software executa
suas funções sob condições estabelecidas.
Conformidade relacionada à eficiência: capacidade do produto de
software de estar de acordo com normas e convenções relacionadas à
eficiência.
Usabilidade: capacidade do produto de software de ser compreendido,
aprendido, operado e atraente ao usuário, quando usado sob condições
especificadas. Suas subcaracterísticas são:
Inteligibilidade: capacidade do produto de software de possibilitar ao
usuário compreender se o software é apropriado e como ele pode ser
usado para tarefas e condições de uso específicas.
Apreensibilidade: capacidade do produto de software de possibilitar ao
usuário aprender sua aplicação.
Operacionalidade: capacidade do produto de software de possibilitar ao
usuário operá-lo e controlá-lo.
Atratividade: capacidade do produto de software de ser atraente ao
usuário.
Conformidade: capacidade do produto de software de estar de acordo
com normas, convenções, guia de estilo ou regulamentações
relacionadas à usabilidade.
Manutenibilidade: capacidade do produto de software de ser modificado.
As modificações podem incluir correções, melhorias ou adaptações do
84
software devido a mudanças no ambiente e nos seus requisitos ou
especificações funcionais. Suas subcaracterísticas são:
Analisabilidade: capacidade do produto de software de permitir o
diagnóstico de deficiências ou causas de falhas no software, ou a
identificação de partes a serem modificadas.
Modificabilidade: capacidade do produto de software de permitir que
uma modificação especificada seja implementada.
Estabilidade: capacidade do produto de software de evitar efeitos
inesperados decorrentes de modificações no software.
Conformidade relacionada à manutenibilidade capacidade do produto
de software de estar de acordo com normas ou convenções
relacionadas à manutenibilidade.
Portabilidade: capacidade do produto de software de ser transferido de
um ambiente para outro. Suas subcaracterísticas são:
Adaptabilidade: capacidade do produto de software de ser adaptado
para diferentes ambientes especificados, sem necessidade de aplicação
de outras ações ou meios além daqueles fornecidos para essa
finalidade pelo software considerado.
Capacidade para ser instalado: capacidade do produto de software para
ser instalado em um ambiente especificado.
Coexistência: capacidade do produto de software de coexistir com
outros produtos de software independentes, em um ambiente comum,
compartilhando recursos comuns.
Capacidade para substituir: capacidade do produto de software de ser
usado em substituição a outro produto de software especificado, com o
mesmo propósito e no mesmo ambiente.
Conformidade relacionada à portabilidade: capacidade do produto de
software de estar de acordo com normas ou convenções relacionadas à
portabilidade.
85
Figura 32: Características e subcaracterísticas da norma ISO/IEC 25010
Fonte: Adaptado de ISO/IEC 25010 (2011)
86
A figura 32 apresenta todas as características e subcaracterísticas previstas
na norma ISO/IEC 25010 que serão detalhadas a seguir (ISO/IEC 25010, 2011).
Adequação funcional: representa o grau em que um produto ou sistema
fornece funções que satisfazem necessidades declaradas e implícitas
quando usadas em condições especificadas. Esta característica é
composta das seguintes subcaracterísticas:
Completude funcional. Grau em que o conjunto de funções cobre todas
as tarefas especificadas e os objetivos do usuário.
Correção funcional. Grau em que um produto ou sistema fornece os
resultados corretos com o necessário grau de precisão.
Adequação funcional. Grau em que as funções facilitam a realização de
tarefas e objetivos específicos.
Eficiência de desempenho: representa o desempenho relativo à
quantidade de recursos utilizados nas condições declaradas. Suas
subcaracterísticas são:
Comportamento do tempo. Grau em que os tempos de resposta e
processamento e as taxas de transferência de um produto ou sistema,
ao executar suas funções, atendem aos requisitos.
Utilização de recursos. Grau em que os valores e tipos de recursos
utilizados por um produto ou sistema, ao executar suas funções,
atendem aos requisitos.
Capacidade. Grau em que os limites máximos de um produto ou
parâmetro do sistema atendem aos requisitos.
Compatibilidade: grau em que um produto, sistema ou componente pode
trocar informações com outros produtos, sistemas ou componentes, e ou
executar as suas funções necessárias, enquanto compartilha o mesmo
ambiente de hardware ou software. Suas subcaracterísticas são:
Coexistência. Grau em que um produto pode desempenhar as suas
funções necessárias de forma eficiente ao compartilhar um ambiente e
recursos comuns com outros produtos, sem prejuízo de qualquer outro
produto.
87
Interoperabilidade. Grau em que dois ou mais sistemas, produtos ou
componentes podem trocar informações e usar as informações que
foram trocadas.
Usabilidade: Grau em que um produto ou sistema pode ser usado por
usuários especificados para alcançar metas especificadas com efetividade,
eficiência e satisfação em um contexto específico de uso. Suas
subcaracterísticas são:
Reconciliação de adequação. Grau em que os usuários podem
reconhecer se um produto ou sistema é apropriado para suas
necessidades.
Aprendizagem. Grau em que um produto ou sistema pode ser usado
por usuários especificados para alcançar objetivos específicos de
aprender a usar o produto ou sistema com eficácia, eficiência, liberdade
de risco e satisfação em um contexto específico de uso.
Operabilidade. Grau em que um produto ou sistema possui atributos
que facilitam o funcionamento e o controle.
Proteção contra erro do usuário. Grau em que um sistema protege os
usuários contra erros.
Estética da interface do usuário. Grau em que uma interface de usuário
permite uma interação agradável e satisfatória para o usuário.
Acessibilidade. Grau em que um produto ou sistema pode ser usado por
pessoas com a mais ampla gama de características e recursos para
alcançar um objetivo especificado em um contexto de uso especificado.
Confiabilidade: Grau em que um sistema, produto ou componente executa
funções especificadas em condições especificadas por um período de
tempo especificado. Suas subcaracterísticas são:
Maturidade. Grau em que um sistema, produto ou componente atende
às necessidades de confiabilidade em operação normal.
Disponibilidade . Grau em que um sistema, produto ou componente é
operacional e acessível quando necessário para uso.
Tolerância ao erro. Grau em que um sistema, produto ou componente
funciona como previsto, apesar da presença de falhas de hardware ou
software.
88
Recuperabilidade. Grau em que, em caso de interrupção ou falha, um
produto ou sistema pode recuperar os dados diretamente afetados e
restabelecer o estado desejado do sistema.
Segurança: grau em que um produto ou sistema protege informações e
dados para que pessoas ou outros produtos ou sistemas tenham o grau de
acesso a dados adequado aos seus tipos e níveis de autorização. Suas
subcaracterísticas são:
Confidencialidade. Grau em que um produto ou sistema garante que os
dados sejam acessíveis apenas aos autorizados a ter acesso.
Integridade. Grau em que um sistema, produto ou componente impede
o acesso não autorizado ou a modificação de programas ou dados
informáticos.
Não repúdio. Grau em que as ações ou eventos podem provar ter
ocorrido, para que os eventos ou ações não possam ser repudiados
mais tarde.
Prestação de contas. Grau em que as ações de uma entidade podem
ser rastreadas exclusivamente para a entidade.
Autenticidade. Grau em que a identidade de um sujeito ou recurso pode
ser comprovada como sendo a reivindicada.
Manutenção: Esta característica representa o grau de eficácia e eficiência
com que um produto ou sistema pode ser modificado para melhorá-lo,
corrigi-lo ou adaptá-lo às mudanças no ambiente e nos requisitos. Suas
subcaracterísticas são:
Modularidade. Grau em que um sistema ou programa de computador é
composto de componentes discretos, de modo que uma mudança para
um componente tenha impacto mínimo em outros componentes.
Reutilização. Grau em que um ativo pode ser usado em mais de um
sistema, ou na construção de outros ativos.
Analisabilidade. Grau de eficácia e eficiência com o qual é possível
avaliar o impacto sobre um produto ou sistema de uma mudança
pretendida para uma ou mais de suas partes, ou para diagnosticar um
produto por deficiências ou causas de falhas, ou para identificar peças a
serem modificadas.
89
Modificabilidade. Grau em que um produto ou sistema pode ser
efetivamente e eficientemente modificado sem apresentar defeitos ou
degradar a qualidade do produto existente.
Testabilidade. Grau de eficácia e eficiência com qual critério de teste
pode ser estabelecido para um sistema, produto ou componente e
testes podem ser realizados para determinar se esses critérios foram
cumpridos.
Portabilidade: Grau de eficácia e eficiência com o qual um sistema,
produto ou componente pode ser transferido de um hardware, software ou
outro ambiente operacional ou de uso para outro. Suas subcaracterísticas
são:
Adaptabilidade. Grau em que um produto ou sistema pode ser
efetivamente e eficientemente adaptado para hardware, software ou
outros ambientes operacionais ou de uso diferentes ou em
desenvolvimento.
Instalabilidade. Grau de eficácia e eficiência com o qual um produto ou
sistema pode ser instalado e ou desinstalado com sucesso em um
ambiente especificado.
Substituibilidade. Grau em que um produto pode substituir outro produto
de software especificado para o mesmo propósito no mesmo ambiente.
90
APÊNDICE B – Testes para definição do ambiente de desenvolvimento
integrado
No universo dos programadores, uma ferramenta é indispensável para a
composição de programas na maioria das linguagens de programação, que são os
IDEs - integrated development environment ou ambiente de desenvolvimento
integrado, que permitem a criação de artefatos de software com amplo suporte ao
desenvolvedor com diversos recursos de apoio, principalmente quando a aplicação
que está sendo concebida possuir elementos sofisticados, como manipulação de
objetos gráficos ou de mídia.
Um outro benefício de lançar mão dos IDEs, é a organização geral em
formato de projetos de programação que os IDEs aplicam para melhor gerir os
muitos arquivos de códigos e metadados que os compõem. Exemplificando,
destaca-se alguns dos IDEs mais conhecidos e utilizados no mundo para
programação em linguagem Java, são eles, Netbeans (2016), Eclipse (2016), IntelliJ
(2016), BlueJ (2016) e Android Studio (2016), entre muitos outros. Foi necessário a
realização de experimentos entre todos os IDES relacionados, afim de se eleger o
mais adequado.
A plataforma de desenvolvimento adotada, ou seja, o IDE mais plausível para
a criação da aplicação proposta foi a Android Studio 2.2.3, frente as outras testadas,
Netbeans 8.0.2 e Eclipse Mars/Helios/Neon. Em todas as plataformas avaliadas,
foram adotadas a linguagem de programação Java para desenvolvimento da
aplicação. Os testes confirmaram o IDE Android Studio devido seu desempenho nos
seguintes quesitos avaliados:
Morosidade na abertura e utilização contínua (performance);
Travamentos;
Gerencialmente do Android emulado diretamente;
Gerenciamento do Android emulado por aplicações externas;
Gerenciamento do Android via conexão por USB;
Disponibilidade de APIs extras e documentação;
Praticidade na utilização durante o desenvolvimento;
Recursos de grag-and-drop e manipulação de fragments;
Comportamento do protótipo nos testes durante o desenvolvimento;
91
Comportamento do protótipo nos testes de software após o
desenvolvimento;
Instabilidades foram observadas em todos os IDEs testados e em vários
momentos distintos e inesperados houve morosidades ou travamentos, mas com
relação ao tempo de abertura da ferramenta, o IDE Android Studio apresentou
resultados inferiores que os outros avaliados, em torno de 130 segundos contra 50
segundos em média dos concorrentes Netbeans e Eclipse, ou seja, houve bem mais
morosidade ao abrir o programa do que seus concorrentes. Também durante a
utilização destas ferramentas, ficou evidente a sensível morosidade do Android
Studio com relação aos concorrentes, que se apresentaram mais ágeis na operação
geral, porém esse fator, apesar de importante, não foi suficiente para desqualificá-lo
para o desenvolvimento da aplicação em questão.
Outro ponto importante foi testado e analisado, o comportamento dos IDEs
nas conexão com os dispositivos móveis por meio de porta USB para transferência
do aplicativo criado, do computador para os dispositivos móveis (upload). Já no uso
virtualizado desses dispositivos gerados a partir do próprio IDE ou através de
soluções externas de terceiros, os chamados emuladores de sistema operacional,
houve diferenças significantes na morosidade entre a forma como os IDEs
manipulavam os dispositivos virtualizados.
A virtualização é desejada quando queremos testar vários tipos e modelos de
dispositivos móveis, mas não dispomos do dispositivo real em mãos. Em todos os
IDEs, quando a virtualização fica a cargo dos emuladores e não do próprio IDE, há
um ganho substancial de tempo de execução e manipulação do objeto virtualizado,
em torno de 30 segundos a menos do que usar apenas o IDE em questão.
O Genymotion é um exemplo de emulador de sistema operacional que
permite executar o Android de forma virtualizada dentro de outro sistema
operacional. Segundo JOSHI et al. (2015), Genymotion é um emulador do Android
que usa a arquitetura x86 para emular diferentes dispositivos Android.
Os IDEs apresentaram equivalência nesses quesitos, seja na conexão por
porta USB, por virtualização de dispositivos móveis ou por uso de emuladores
externos. Contudo, relata-se que houve morosidade em vários momentos ao optar-
92
se pela virtualização ao invés de conexão por USB e até mesmo travamentos foram
presenciados e resolvidos com a inicialização dos IDEs. A conexão por porta USB é
a que se apresenta como a solução mais adequada, estável e ágil para testes com a
aplicação durante o desenvolvimento, no entanto, o ponto negativo pode estar na
falta de diversidades de modelos de dispositivos móveis a mão, ao contrário da
abundância de modelos que são proporcionados pela virtualização.
No entanto, um item importante e determinante se observa no IDE Android
Studio, um recurso chamado drag-and-drop (arrastar e soltar), disponibilizado
através de APIs em todas as IDE e necessário nesse tipo de aplicação
desenvolvida, apresentou-se de forma muito mais satisfatória em aplicações criadas
no Android Studio.
Outro quesito relevante, o Android Studio se apresenta como uma interface
moderna com recursos bem organizados, com barras de ferramentas e outras
funcionalidades bem acessíveis e descomplicadas. A Figura 33 demarca pontos
importantes do IDE que serão apresentados a seguir (ANDROID STUDIO, 2016).
Figura 33: IDE Android Studio
Fonte: Android Studio (2016)
93
1. A barra de ferramentas permite executar uma grande variedade de ações,
incluindo a execução de aplicativos e a inicialização de ferramentas do Android.
2. A barra de navegação ajuda a navegar pelo projeto e a abrir arquivos para
edição. Ela oferece uma visualização mais compacta da estrutura visível na
janela Project.
3. A janela do editor é o local onde você cria e modifica código. Dependendo do
tipo de arquivo atual, o editor pode mudar. Por exemplo, ao visualizar um
arquivo de layout, o arquivo exibe o Editor de layout.
4. As janelas de ferramenta permitem acessar tarefas específicas como
gerenciamento de projetos, pesquisa e controle de versões, entre outras. As
janelas podem ser expandidas e recolhidas.
5. A barra de status exibe o status do projeto e do próprio IDE, bem como todos
os avisos ou mensagens.
A tabela 4 sintetiza os critérios de avaliação relatados até aqui dos três IDEs
testados da seguinte forma, nota A, B ou C, dependendo do comportamento do item
avaliado, para ótimo, bom e regular.
Tabela 4: Avaliação dos IDEs
Testes e Experimentos Android
Studio Netbeans Eclipse
Performance B B B
Travamentos C C C
Android emulado pela IDE C C C
Android emulado pelo Genymotion B B B
Android por USB; A A A
APIs extras e documentação A B B
Praticidade na utilização B C C
Recursos de grag-and-drop B C C
Recursos de fragments B B B
Comportamento do protótipo A B B
Legenda : A – Ótimo B – Bom - C – Regular
94
APÊNDICE C – Algoritmos adotados para a criação do protótipo Simuni9
No desenvolvimento do protótipo de um aplicativo, o Simuni9, para rodar em
dispositivos móveis, como tablets e smartphones, com o sistema Android, foram
necessários a utilização de dispositivos físicos e virtualizados, conectados ao
computador ou emulados com softwares de virtualização, que permitiram testar o
protótipo em várias versões do sistema Android e diversos modelos de dispositivos
móveis.
A escolha pelo sistema operacional Android para mobile e a linguagem de
programação Java, foi devido ao fato de serem os softwares para mobile mais
utilizados no Brasil e no mundo, dentro dos seus segmentos, segundo levantamento
da IDC Analyze the Future. Em agosto de 2016, o sistema Android possuía 87,6%
entre os smartphones comercializados (IDC, 2016) e (IEEE SECTRUM, 2014).
A criação do protótipo pode auxiliar em outra preocupação da pesquisa, se
efetivamente as ferramentas e recursos disponíveis nos dispositivos móveis são
suficientes e satisfatórios para a criação de um aplicativo pleno para atuar na área
da modelagem e simulação computacional e qual o comportamento de um aplicativo
como esse nesse ambiente. Logo, um protótipo dessa aplicação se fez necessário,
além de obviamente servir de caso de teste para a abordagem de teste proposta
neste estudo.
Algumas questões técnicas e operacionais precisavam de respostas para
avaliar o comportamento de um aplicativo relacionado ao propósito da pesquisa, em
um dispositivo com características técnicas menores ou diferentes que os
computadores convencionais, como tamanho de tela, capacidade de memória e
processamento, operação por toque (touch-screen) e movimentação de objetos por
arrastar e soltar (drag-and-drop).
Também outra importante funcionalidade precisou ser implementada no
protótipo do aplicativo. Como visto na seção 2.8.2, para aplicações voltadas à área
da modelagem e simulação computacional no contexto desse trabalho, há
necessidade da geração de números aleatórios segundo algum tipo de distribuição
de probabilidade. Para tanto, a funcionalidade implementada ao protótipo permite a
geração de 10.000 números pseudoaleatórios segundo as seguintes distribuições de
95
probabilidades: exponencial, normal ou triangular. Para análise destes resultados foi
utilizado a ferramenta Input Analyzer para aferir os testes estatístico de aderência e
comprovar a distribuição esperada, como poderá ser visto no capítulo 4 de
resultados.
Outro fator de observação e análise foi com relação ao tempo de execução da
referida funcionalidade na geração dos números estava dentro de limites aceitáveis
para uma aplicação de modelagem e simulação, incluindo o tempo de registro dos
dados em arquivo do tipo texto.
Na seção seguinte serão apresentados os algoritmos em formato de
pseudocódigos que representam algumas das funcionalidades essenciais para o
aplicativo, a funcionalidade de geração de números pseudoaleatório com diferentes
distribuições de probabilidades e o algoritmo adotado para implementar o sistema de
filas, que são as maiores complexidades de um software deste tipo.
Definição dos algoritmos para geração de números pseudoaleatórios e sistema
de filas
Para testar a capacidade dos dispositivos móveis gerarem números
pseudoaleatório estatisticamente distribuídos, foram realizados seis experimentos,
destes, três em uma aplicação criada em linguajem Java para rodar em dispositivos
móveis, e os outros três utilizando o recurso de geração de números aleatório do
Input Analyzer para comparações dos resultados.
Todos os experimentos geraram com sucesso 10.000 números
pseudoaleatórios para cada uma das distribuições de probabilidades adotadas
nesse estudo, ou seja, exponencial, normal e triangular.
Para análise dos resultados, os dados foram importados para a ferramenta
Input Analyzer utilizando-se da opção Fit All.
Os algoritmos de referência utilizados na aplicação em Java para geração
dos 10.000 números aleatórios em cada tipo de distribuição de probabilidade são
apresentados em formato de pseudocódigo nas figuras 34, 35 e 36 a seguir.
96
Figura 34: Algoritmo com distribuição exponencial
Fonte: Santos (1999)
Figura 35: Algoritmo com distribuição normal
Fonte: Santos (1999)
97
Figura 36: Algoritmo com distribuição triangular
Fonte: Santos (1999)
Para descrever o sistema de filas, Chwif e Medina (2010) apresentam um
algoritmo genérico, que pode ser visto nas figuras 37 e 38, dividido em duas partes.
O algoritmo demonstra os passos básicos para um sistema de filas que adota
aleatoriedade de números exponencialmente distribuídos, com média 10 para o
tempo entre chegadas (TC=10) e média 8 para o tempo médio de atendimento (TA)
e não aborda outras distribuições, contudo no protótipo do aplicativo criado, foram
implementadas também as distribuições normal e triangular.
98
Figura 37: Algoritmo modelo de sistema de fila – Parte 1
Fonte: Chwif e Medina (2010)
99
Figura 38: Algoritmo modelo de sistema de fila – Parte 2
Fonte: Chwif e Medina (2010)