mas funcionalidades, como por exemplo: durante a visualizac¸˜ao do relat´orio em tela deveria ser poss´ıvel ver cada p´agina separadamente, no mesmo formato em que ser´a realmente impresso, ao inv´es de ver o relat´orio em um ´unico texto com uma barra de rolagem vertical, que ´e o que ocorre na vers˜ao atual.
6.10
Avaliac¸ ˜ao do GREN-Wizard
O GREN-Wizard foi avaliado em sec¸˜oes anteriores quanto `a facilidade de uso na instanciac¸˜ao do GREN. Outros fatores que merecem ser discutidos s˜ao o desempenho do GREN-Wizard e suas limitac¸˜oes.
Algumas medidas tomadas durante o uso do GREN-Wizard s˜ao mostrados na Tabela 6.22. Elas referem-se `a implementac¸˜ao de trˆes sistemas pela autora desta tese: o SARB (ver sec¸˜ao 5.7), um sistema de hotel e um sistema para loja de venda e aluguel de produtos para festas. O n´umero de padr˜oes aplicados foi inclu´ıdo para dar uma noc¸˜ao do tamanho do sistema. Por exemplo, o sistema de hotel ´e bem menor do que o sistema de loja para festas. Deve-se observar que essas medidas s˜ao influenciadas pela experiˆencia de quem a utilizou, no caso a pr´opria desenvolvedora do GREN-Wizard. Antes de iniciar o preenchimento dos formul´arios em tela, a GRN j´a tinha sido aplicada e havia sido constru´ıda uma tabela com os padr˜oes aplicados, pap´eis desempenhados e atributos adicionados, conforme recomendado na sec¸˜ao 3.4. Uma das tarefas que demanda maior tempo no preenchimento dos formul´arios em tela ´e a inclus˜ao de novos atributos, pois ´e necess´ario especificar seu tipo e tamanho. Al´em disso, se os atributos forem de tipos especiais, como por exemplo valores vindos de uma lista, deve-se fornecer os detalhes sobre essa lista, o que aumenta o tempo de preenchimento das telas.
Tabela 6.22: Medidas de uso do GREN-Wizard
Medida SARB Hotel Loja Festas
Nro de padr˜oes utilizados 9 5 13 Total de atributos inclu´ıdos 7 16 15 Nro de classes criadas 26 21 41 Nro de m´etodos criados 195 181 266 Nro de tabelas criadas na base de dados 14 13 22
Nro de linhas de c´odigo geradas 1400 1300 2000 Tempo gasto na gerac¸˜ao do c´odigo 20s 23s 37s Tempo gasto no preenchimento dos formul´arios em tela 7min30s 10min 15min
O tempo gasto na gerac¸˜ao refere-se ao tempo aproximado dispendido pelo m´odulo de gerac¸˜ao de c´odigo para criar as classes, m´etodos e tabelas MySQL. Esse tempo ´e bastante influenciado pela quantidade e tipo dos atributos adicionados, pois atributos novos exigem a criac¸˜ao de diversos m´etodos, incluindo os m´etodos para inseri-los nas classes de interface gr´afica com o usu´ario.
6.10 Avaliac¸˜ao do GREN-Wizard 157 Foram tomadas outras medidas do tempo necess´ario para preenchimento dos formul´arios em tela, pelos alunos participantes do E-GRN-GREN. Eles levaram entre trinta e quarenta e cinco minutos para preencher os formul´arios do GREN-Wizard para instanci´a-lo para o sistema de cl´ınica veterin´aria (em m´edia foram trinta minutos). Esses participantes tiveram treinamento de cerca de meia hora a respeito do GREN-Wizard e depois receberam o manual a ser estudado antes de seu uso.
As medidas de tempo para uso do GREN-Wizard indicam que ´e poss´ıvel obter aplicac¸˜oes no dom´ınio de gest˜ao de recursos de neg´ocios em poucos minutos. Deve-se lembrar que nem sem- pre se consegue modelar toda a funcionalidade do sistema com a GRN e, conseq¨uentemente, o c´odigo gerado dever´a ser complementado para atender aos requisitos n˜ao cobertos. Ainda assim, aconselha-se a utilizac¸˜ao do GREN-Wizard para obtenc¸˜ao da parte do c´odigo referente aos requi- sitos atendidos pela GRN, para depois iniciar-se a implementac¸˜ao dos demais requisitos.
Quanto `as limitac¸˜oes do GREN-Wizard, pode-se citar algumas sugest˜oes feitas por pessoas que o utilizaram ou que assistiram a uma demonstrac¸˜ao durante a sess˜ao de ferramentas do Simp´osio Brasileiro de Engenharia de Software de 2002. A navegac¸˜ao entre os padr˜oes ´e uma das de- ficiˆencias do GREN-Wizard, pois n˜ao existe um bot˜ao para voltar ao padr˜ao aplicado anterior- mente. Na implementac¸˜ao atual, caso seja necess´ario voltar ao padr˜ao anterior, deve-se salvar a especificac¸˜ao corrente, retornar ao primeiro padr˜ao aplicado e ent˜ao percorrer novamente todos os padr˜oes at´e chegar ao padr˜ao desejado. Esse requisito poder´a ser implementado na pr´oxima vers˜ao da ferramenta. Outro ponto a ser melhorado ´e com relac¸˜ao a participantes opcionais dos padr˜oes. Em alguns casos foram criados variantes do padr˜ao para permitir que um participante fosse opci- onal, por exemplo, no padr˜ao 4-LOCAR O RECURSO, existe um variante “Sem Origem”, no qual o participante “Origem” n˜ao ´e utilizado. Em outros casos simplesmente ´e permitido que o par- ticipante seja deixado em branco durante o preenchimento dos formul´arios em tela. Na pr´oxima vers˜ao da ferramenta pretende-se unificar o tratamento desse caso, dando preferˆencia `a segunda alternativa, que ´e de permitir que o participante fique em branco. Haver´a uma indicac¸˜ao na tela de que o participante ´e opcional, por exemplo, o nome estar´a em it´alico.
Outro tipo de limitac¸˜ao existente no GREN-Wizard ´e quanto `a possibilidade de modificac¸˜ao dos padr˜oes da GRN sem perder as informac¸˜oes presentes na base de dados. Por exemplo, se a definic¸˜ao dos participantes de um padr˜ao for modificada, a base de dados que cont´em a especifica- c¸˜ao das aplicac¸˜oes j´a modeladas com a GRN teria que ser revisada para manter a compatibilidade com a nova vers˜ao. Isso seria desej´avel para garantir o prop´osito de reutilizar a especificac¸˜ao de aplicac¸˜oes j´a desenvolvidas quando forem criadas aplicac¸˜oes similares. Para resolver esse pro- blema, ser´a necess´ario avaliar todas as possibilidades de mudanc¸a na definic¸˜ao dos padr˜oes e estu- dar as conseq¨uˆencias dessas mudanc¸as nas aplicac¸˜oes modeladas usando a GRN.
6.11 Considerac¸˜oes Finais 158
6.11
Considerac¸ ˜oes Finais
Deve-se ressaltar que a avaliac¸˜ao realizada para os diversos processos e produtos est´a atrelada aos produtos espec´ıficos: GRN, GREN e GREN-Wizard. Assim, n˜ao se pode generalizar os resultados para outras linguagens de padr˜oes, frameworks eWizards. Por exemplo, nada garante que outras
linguagens de padr˜oes de an´alise, escritas por autores diferentes, com n´ıvel distinto de detalhes e usando outro estilo para documentar os padr˜oes, sejam ou n˜ao ´uteis na modelagem de sistemas. Da mesma forma, outros frameworks constru´ıdos com base em linguagens de padr˜oes podem estar documentados de forma inadequada quanto ao prop´osito de permitirem a instanciac¸˜ao tal qual proposto nesta tese.
Em suma, os resultados confirmam o forte relacionamento existente entre linguagens de pa- dr˜oes e frameworks sugerido em diversos trabalhos existentes (Beck e Johnson, 1994; Brugali e Menga, 1999; Johnson, 1992) (ver sec¸˜ao 2.5). Pode-se tirar proveito desse relacionamento, por exemplo utilizando o processo geral proposto nesta tese, para acelerar o processo de desenvolvi- mento de sistemas num particular dom´ınio.
Os experimentos relatados nas sec¸˜oes 6.3.2, 6.3.3, 6.3.4 e 6.5.2, juntamente com a experiˆencia adquirida na sua realizac¸˜ao, podem servir de base para o planejamento de novos experimentos que mostrem com significˆancia o valor dos processos e produtos apresentados nesta tese.
A an´alise efetuada neste Cap´ıtulo forneceu ind´ıcios da utilidade dos processos propostos para os v´arios profissionais da Engenharia de Software, conforme almejado nos objetivos desta tese (ver sec¸˜ao 1.3). O desenvolvedor de frameworks pode se beneficiar dos processos de construc¸˜ao de fra- meworks e deWizards, conforme relatado nas sec¸˜oes 6.2, 6.4 e 6.6. O desenvolvedor de aplicac¸˜oes
experiente pode usar os processos para uso de uma linguagem de padr˜oes, seu framework associado ewizard (se houver), para agilizar o desenvolvimento de software, conforme discutido nas sec¸˜oes
6.3, 6.5 e 6.7. O desenvolvedor de aplicac¸˜oes inexperiente pode usar a linguagem de padr˜oes para modelar seu sistema ewizard para produzir o c´odigo final (tamb´em conforme discutido nas sec¸˜oes
6.3, 6.5 e 6.7). Al´em disso, outros profissionais que podem usar as tecnologias propostas s˜ao: o analista de dom´ınio, que pode usar o processo de construc¸˜ao de linguagens de padr˜oes, conforme discutido na sec¸˜ao 6.2; o testador de software, que pode utilizar o wizard para acelerar o teste do
framework, conforme mencionado na sec¸˜ao 6.8; e o construtor de aplicac¸˜oes para o dom´ınio de gest˜ao de recursos de neg´ocios, que pode utilizar a GRN, o GREN e o GREN-Wizard para modelar e implementar seus sistemas nesse dom´ınio.
No pr´oximo Cap´ıtulo resume-se o trabalho efetuado, listando suas principais contribuic¸˜oes, limitac¸˜oes e poss´ıveis trabalhos futuros.
C
AP´
ITULO7
Conclus ˜oes
7.1
Considerac¸ ˜oes Iniciais
Este Cap´ıtulo resume o trabalho efetuado e lista suas contribuic¸˜oes para a ´area de Engenharia de Software e Sistemas de Informac¸˜ao, bem como suas limitac¸˜oes. Aponta tamb´em os traba- lhos futuros que podem ser realizados em continuidade a este trabalho, que poder˜ao gerar outras contribuic¸˜oes.