Esse estudo de observação acorreu no contexto da disciplina de graduação Engenharia de Software Orientada a Objetos ministrada no 2º semestre de 2008 na UFRJ.
2.4.1 Objetivo
Analisar o uso de modelos no desenvolvimento de aplicações Web, com o propósito de caracterizar,
com respeito à viabilidade e relevância dos modelos (percepção de esforço, dificuldade e importância),
do ponto de vista do pesquisador,
no contexto do desenvolvimento de uma aplicação Web para Controle de Inventário Patrimonial por alunos de graduação do curso de Engenharia de Computação e Informação da UFRJ.
2.4.2 Contexto
Nesse estudo os participantes focaram novamente em uma única aplicação Web. A escolha da aplicação baseou-se, principalmente, no interesse dos pesquisadores em aumentar o grau de complexidade da aplicação a ser modelada. Assim, a especificação da aplicação de Controle de Inventário Patrimonial (usada no primeiro estudo) foi revista e ampliada para que novos casos de uso fossem
22 incorporados. A nova versão da especificação passou a ser composta por 17 casos de uso.
2.4.3 Projeto do Estudo
A divisão das equipes seguiu dois critérios: a experiência dos participantes e a assiduidade nas aulas, de forma a manter os alunos mais assíduos em um mesmo grupo. O critério da assiduidade foi adotado para que os alunos que tiveram menor participação nas aulas teóricas não influenciassem negativamente no desempenho daqueles que participaram de todas as discussões envolvendo a construção dos modelos. Foram definidas dez equipes com três participantes e uma equipe com quatro participantes. As equipes tiveram a liberdade de se organizarem internamente e não foi exigido que nenhum processo de desenvolvimento específico fosse seguido. Foi sugerido que as equipes utilizassem os diagramas de classes, seqüência, atividades e estado, o mapa de atores e o mapa navegacional. Entretanto, cada equipe poderia abdicar do uso de qualquer um desses modelos, se assim desejasse. Ao final, cada equipe deveria entregar um documento de projeto com os modelos construídos, além de realizar uma apresentação de 20 minutos ressaltando os principais pontos do projeto. É importante ressaltar que a perspectiva de apresentação foi excluída desse estudo porque os seus modelos se demonstraram os menos aderentes aos padrões de modelagem aplicados neste trabalho, particularmente no que diz respeito ao uso da UML. Novas investigações são necessárias no sentido de aprimorar a percepção de como os aspectos estruturais e comportamentais dessa perspectiva podem ser representados em um contexto de desenvolvimento dirigido por modelos.
2.4.4 Instrumentação
Foram entregues aos participantes a especificação da aplicação e um template para preparação da apresentação da equipe, direcionando a apresentação para as questões de interesse dos pesquisadores. Também foi disponibilizada a ferramenta BOUML (PAGÉS, 2011) juntamente com perfis UML (OMG, 2010a) para construção do modelo navegacional, segundo o método OOWS (PASTOR et al., 2001). Novamente houve mudança da ferramenta em relação o estudo anterior. Nesse caso, a mudança foi motivada pela descontinuação da ferramenta StarUML, que naquele momento não implementava inovações importantes da especificação UML 2.0, principalmente em relação aos diagramas de estado e atividades.
23 2.4.5 Execução
As equipes tiveram quatro semanas para realizar a modelagem da aplicação proposta e, após a entrega dos trabalhos, os participantes foram convidados a responderem, individualmente, um questionário sobre as suas percepções acerca dos modelos utilizados.
O questionário final foi respondido por 23 dos 34 participantes e continha quatro questões quantitativas e uma qualitativa sobre o uso dos modelos. Para que as respostas do questionário pudessem ser analisadas de forma isenta, a primeira pergunta procurou definir o nível de participação que cada integrante da equipe teve em relação à elaboração dos modelos. A Tabela 2-6 sumariza esse nível de participação.
Tabela 2-6 - Atuação dos desenvolvedores por modelo Tipo de
participação
Classe Seqüência Estado Atividade Ator Navega- ção Não construiu nem
revisou
0,0% 0,0% 13,1% 34,8% 26,1% 17,4%
Só revisou 8,7% 17,4% 21,7% 26,1% 34,8% 39,1%
Só construiu 8,7% 17,4% 8,7% 0,0% 8,7% 13,1%
Construiu e revisou 82,6% 65,2% 56,5% 39,1% 30,4% 30,4%
Para as demais questões quantitativas, as opiniões dos participantes que não tiveram nenhum contato com o modelo foram expurgadas das estatísticas, ou seja, os indivíduos que nem construíram e nem revisaram o modelo tiveram a sua opinião removida da estatística.
A segunda questão procurou capturar o esforço de construção de cada modelo na percepção dos participantes. As repostas possíveis, nesse caso, eram Alto, Médio ou Baixo. A Tabela 2-7 resume a percepção de esforço dos participantes, além de destacar essa percepção para as três equipes que apresentaram os melhores projetos e para as três equipes que apresentaram os piores projetos. É possível notar que, independente da qualidade do projeto, o esforço percebido pelas equipes segue um comportamento semelhante.
Tabela 2-7 - Percepção de esforço
Diagrama Esforço Percebido Equipes com melhores projetos Equipes com piores projetos Total Total de opiniões Classe Alto 8 7 15 23 Médio 4 3 7 Baixo 0 1 1 Seqüência Alto 11 6 17 23 Médio 1 5 6 Baixo 0 0 0
24 Estado Alto 0 0 0 21 Médio 3 2 5 Baixo 9 7 16 Atividade Alto 0 1 1 17 Médio 10 4 14 Baixo 1 1 2 Ator Alto 0 0 0 19 Médio 1 0 1 Baixo 11 7 18 Navegação Alto 9 8 17 22 Médio 3 1 4 Baixo 0 1 1
Levando em consideração somente a opinião dos participantes que criaram os artefatos, a Tabela 2-8 apresenta o percentual de distribuição do esforço percebido por diagrama.
Tabela 2-8 - Distribuição de percepção de esforço dos participantes que criaram os artefatos Esforço
percebido
Classe Seqüência Estado Atividade Ator Navegação
Alto 61,9% 73,7% 0,0% 11,1% 0,0% 90,0%
Médio 33,3% 26,3% 26,7% 66,7% 11,1% 0,0%
Baixo 4,8% 0,0% 73,3% 22,2% 88,9% 10,0%
Total 100% 100% 100% 100% 100% 100%
A terceira questão teve como foco a importância de cada modelo na percepção dos participantes do estudo, onde as respostas possíveis variavam de 0 (nenhuma importância) a 6 (muito importante). Visando realizar uma avaliação mais justa, a resposta de cada participante foi multiplicada por um peso que indicava como o participante manipulou o artefato:
Não criou nem revisou: peso 0;
Só revisou: peso 1;
Só criou: peso 2, e;
Criou e revisou: peso 3.
A Tabela 2-9 resume a distribuição de importância percebida pelos participantes por diagrama, destacando para cada diagrama as importâncias que obtiveram votação mais expressiva.
Tabela 2-9 - Distribuição de importância percebida pelos participantes por diagrama
Importância Percebida
Classe Seqüência Estado Atividade Ator Navega- ção
0 – sem importância 0,0% 0,0% 1,4% 0,9% 0,6% 0,0%
1 0,0% 0,0% 12,4% 2,6% 66,9% 9,2%
2 0,0% 0,0% 11,1% 6,8% 9,6% 51,5%
25
4 0,0% 10,6% 18,4% 61,5% 0,0% 30,7%
5 0,2% 68,8% 0,0% 17,9% 13,4% 6,1%
6 – muito importante 99,8% 15,6% 1,4% 0,0% 0,0% 1,8%
Total 100% 100% 100% 100% 100% 100%
Nessa questão os participantes puderam apontar até três fatores de uma lista pré-definida de nove fatores, a saber:
1. Treinamento (exemplos, qualidade do material disponibilizado entre outros);
2. Complexidade do sistema (dificuldade de entendimento do domínio); 3. Documento de especificação (documentação confusa e/ou inadequada); 4. Falta de experiência na criação do modelo;
5. Ferramenta case (componentes inadequados para construção do modelo); 6. Complexidade do diagrama;
7. Ordem com que os modelos foram construídos;
8. Divisão de tarefas/responsabilidades entre a equipe, e; 9. Perspectiva de projeto inconsistente usada pela equipe.
A criação dessa lista de fatores se baseou nas análises feitas nos questionários dos primeiro e segundo estudos de observação anteriormente descritos. A Tabela 2-10 sumariza os três fatores que trouxeram mais dificuldades para cada modelo na percepção dos participantes do estudo.
Tabela 2-10 - Fatores de dificuldade apontados pelos participantes
Dificuldade Classe Seqüência Estado Atividade Ator Navega- ção Falta de experiência na criação do modelo Ferramenta CASE Divisão de tarefas Treinamento Documento de especificação Complexidade do diagrama Ordem de construção dos modelos
A quinta e última questão foi concebida com o intuito de capturar o que poderia ser feito, na opinião dos participantes, para diminuir o esforço ou eventuais dificuldades no uso desses modelos. A pergunta formulada foi:
26
Na sua opinião de engenheiro de software, o que poderia ser feito para diminuir o esforço/dificuldade com estes modelos?
Foi solicitada uma resposta separada para cada um dos modelos envolvidos no estudo. Por se tratar de uma questão aberta as respostas dos participantes foram analisadas de acordo com as codificações aberta e axial propostas por STRAUSS e CORBIN (1998) para o método Grounded Theory. Como a pergunta formulada era bastante específica, o processo de codificação/categorização procurou interpretar as respostas em busca dos fatores facilitadores propostos pelos participantes. As respostas dos participantes, bem como análise dessas respostas dados e os códigos extraídos estão detalhados no apêndice B. Um resumo dos códigos e categorias obtidos nessa análise será apresentado na próxima seção.
A próxima seção apresenta uma análise sobre o uso de modelos em um cenário de desenvolvimento Web à luz dos resultados obtidos nos três estudos de observação realizados.