proposto no manual de instanciac¸˜ao (ou cookbook) por pessoas que n˜ao conheciam o projeto do
GREN. Inicialmente ele foi utilizado para implementar o sistema de hotel e o sistema de locadora de carros (j´a utilizado em experimentos anteriores, descritos na sec¸˜ao 6.3) pelos mesmos alunos que participaram do E-GRN-1. Partindo do resultado do E-GRN-1, que foi o modelo de an´alise do sistema, devidamente corrigido de acordo com o gabarito proposto, metade dos grupos realizou a implementac¸˜ao do sistema de hotel e, a outra metade, do sistema de locadora de carros. Os alunos utilizaram ocookbook do GREN para guiar a instanciac¸˜ao, no qual ´e expl´ıcita a utilizac¸˜ao da GRN
durante todo o processo. O estudo de caso cumpriu seu prop´osito, visto que os alunos puderam efe- tuar a instanciac¸˜ao de maneira sistem´atica, sem necessidade de conhecimento da estrutura interna do GREN. As dificuldades relatadas pelos alunos foram anotadas e uma nova vers˜ao docookbook
foi produzida ap´os o caso de uso.
Em outro caso de uso, uma aluna de doutorado, tamb´em do ICMC-USP, usou o GREN para instanciar um sistema real de Controle de Estoque, cujos requisitos n˜ao se adequavam totalmente ao dom´ınio da GRN. Nesse caso, a GRN foi ´util para avaliar a adequac¸˜ao do GREN para imple- mentar a aplicac¸˜ao espec´ıfica. Como a GRN n˜ao conseguiu dar cobertura a um n´umero suficiente de requisitos do sistema de controle de estoque em m˜aos, concluiu-se que o uso do GREN n˜ao traria muitos ganhos, porque muita programac¸˜ao adicional seria necess´aria para implementar as func¸˜oes n˜ao cobertas por ele. Mesmo assim, a aluna efetuou a instanciac¸˜ao referente aos requisi- tos cobertos, com base nocookbook do GREN, instanciando apenas os padr˜oes referentes a esses
requisitos. A aluna estima que foram cobertos cerca de 65% dos requisitos. Trinta e cinco classes foram criadas, num total de aproximadamente duas mil e duzentas LOC. Considera-se esse resul- tado satisfat´orio comparado `a implementac¸˜ao do sistema partindo do nada. No entanto, como ser´a necess´ario programar grande parte do c´odigo, outras alternativas de reuso poderiam ser estudadas para tentar alcanc¸ar o m´aximo de reuso poss´ıvel.
6.6
Avaliac¸ ˜ao da utilidade de uma linguagem de padr ˜oes
na construc¸ ˜ao de um Wizard
Desenvolver umWizard para auxiliar na instanciac¸˜ao de um framework que tenha sido constru´ıdo
com base em uma linguagem de padr˜oes, pode trazer uma s´erie de vantagens, principalmente se o projeto desse Wizard for gen´erico, prevendo sua adaptac¸˜ao futura para outros pares “fra-
mework e linguagem de padr˜oes”, conforme discutido na sec¸˜ao 5.8. Embora o processo proposto naquela sec¸˜ao ainda n˜ao tenha sido utilizado na pr´atica, ele foi derivado a partir da experiˆencia de construc¸˜ao do GREN-Wizard com base na GRN, conforme descrito na sec¸˜ao 5.5. A generalizac¸˜ao
6.7 Avaliac¸˜ao da utilidade de uma linguagem de padr˜oes na instanciac¸˜ao de um framework
usando seuWizard 151
foi feita com base em um caso concreto e cujos problemas certamente s˜ao representativos da classe de problemas encontrados no desenvolvimento de uma ferramenta desse tipo.
Algumas vantagens de uma linguagem de padr˜oes na construc¸˜ao de umWizard s˜ao:
• o m´odulo de especificac¸˜ao do dom´ınio pode ser reaproveitado de outros desenvolvimentos de Wizards, j´a que os elementos dos padr˜oes que devem ser representados s˜ao sempre os
mesmos, por exemplo, padr˜oes, variantes, classes, atributos, relacionamentos e ordem de aplicac¸˜ao dos padr˜oes. No caso de j´a existir um Wizard gen´erico esse reaproveitamento ´e
ainda mais direto.
• o projeto da GUI doWizard fica mais f´acil, pois deve obedecer aos padr˜oes da linguagem.
No caso de j´a existir um Wizard gen´erico, a GUI pode ser totalmente reaproveitada, pois
seu projeto depende apenas da correta adaptac¸˜ao da base de dados com os meta-dados sobre a linguagem de padr˜oes. Mesmo no caso de construc¸˜ao de um Wizard espec´ıfico, tem-se
em m˜aos o projeto arquitetural da GUI, ou seja, a estrutura geral pode ser reaproveitada, cuidando apenas das telas que mostram cada padr˜ao individual.
• o m´odulo gerador de c´odigo possui algumas func¸˜oes que n˜ao variam de uma linguagem de padr˜oes para outra e que, portanto, podem ser reaproveitadas. Mesmo em um Wizard
espec´ıfico, pode-se reusar alguns algoritmos gen´ericos, como os fornecidos nas Figuras 5.10 e 5.11.
Acredita-se que outros desenvolvedores de frameworks possam utilizar o processo proposto para construc¸˜ao de seus frameworks e ferramentas de instanciac¸˜ao, contribuindo para o aperfei- c¸oamento do processo proposto `a medida que outros problemas forem sendo encontrados. Um dos trabalhos futuros sugeridos na sec¸˜ao 7.5 ´e de estudar o GREN-Wizard e modificar algumas partes de seu projeto para que ele possa ser considerado um Wizard gen´erico. Isso permitir´a sua
adaptac¸˜ao para funcionamento com o framework Qd+ e a linguagem de padr˜oes LV.
6.7
Avaliac¸ ˜ao da utilidade de uma linguagem de padr ˜oes
na instanciac¸ ˜ao de um framework usando seu Wi-
zard
Tendo sido oWizard constru´ıdo com base em uma linguagem de padr˜oes, ´e intuitivo que esta seja
essencial durante a utilizac¸˜ao do mesmo. A avaliac¸˜ao aqui apresentada baseia-se no uso do GREN- Wizard guiado pela GRN, j´a que n˜ao se disp˜oe de outrosWizards constru´ıdos seguindo o processo
6.7 Aval. utilidade ling. padr˜oes na inst. de um framework usando seuWizard 152 proposto. Uma nova avaliac¸˜ao poder´a ser feita ap´os a realizac¸˜ao do trabalho de construc¸˜ao de um
Wizard gen´erico com base na modificac¸˜ao do GREN-Wizard.
Diversos usos do GREN-Wizard foram realizados para identificar dificuldades, vantagens e desvantagens. O orientador desta tese foi quem primeiro usou o GREN-Wizard, ap´os um breve treinamento destinado a prepar´a-lo para uma demonstrac¸˜ao da ferramenta em uma Conferˆencia Internacional. Sendo co-autor da GRN, foi dispens´avel fazer o estudo da mesma. O treinamento, que foi de cerca de uma hora, demonstrou ser suficiente para iniciar o uso do GREN-Wizard. O exemplo escolhido para o treinamento foi o SARB (ver sec¸˜ao 3.5.6), para o qual j´a se dispunha da modelagem usando a GRN. Depois disso foi escolhido um outro sistema, bem mais simples, para servir de exemplo na demonstrac¸˜ao da ferramenta, devido ao curto tempo reservado para tal na Conferˆencia. Algumas dificuldades no uso da GUI foram relatadas e s˜ao discutidas na sec¸˜ao 6.10. Quanto ao uso da GRN durante a instanciac¸˜ao, n˜ao houve dificuldade.
Outros usos do GREN-Wizard foram realizados6 pela mesma aluna de doutorado que havia
instanciado manualmente algumas aplicac¸˜oes usando o cookbook do GREN. Os sistemas instan-
ciados usando o GREN-Wizard foram um sistema de biblioteca e um sistema de oficina de apa- relhos eletrˆonicos, que j´a haviam sido modelados usando a GRN (ver sub-sec¸˜ao 6.3.5), mas ainda n˜ao tinham sido implementados. N˜ao houve treinamento espec´ıfico para essa aluna, tendo apenas sido fornecido o manual de uso do GREN-Wizard. Aqui, novamente, foram identificados alguns problemas de usabilidade na GUI do GREN-Wizard, que s˜ao discutidos na sec¸˜ao 6.10. A aluna tamb´em n˜ao teve dificuldade no uso da GRN durante a instanciac¸˜ao, tendo relatado que a interac¸˜ao ´e bastante f´acil e intuitiva, ou seja, conhecendo-se a GRN ´e poss´ıvel utilizar o GREN-Wizard sem maiores problemas. Ela mencionou que a existˆencia de bot˜oes que habilitam e desabilitam guiam o usu´ario na aplicac¸˜ao da linguagem de padr˜oes. Comparou o uso do GREN-Wizard `a instanciac¸˜ao manual, dizendo que o c´odigo produzido peloWizard ´e semelhante ao c´odigo programado manu-
almente e que pode ser facilmente modificado caso necess´ario.
Alguns requisitos dos sistemas de biblioteca e oficina eletrˆonica n˜ao puderam ser atendidos pelo GREN e, conseq¨uentemente, pelo GREN-Wizard. Analisando esses requisitos, percebeu-se que seria desej´avel inclu´ı-los no GREN, j´a que s˜ao funcionalidades que fazem parte do dom´ınio e podem ser reusadas em outras futuras aplicac¸˜oes do GREN. Assim, a aluna se propˆos a fazer uma manutenc¸˜ao, tanto no GREN quanto no GREN-Wizard, para incluir essas funcionalidades, que referem-se basicamente aos tipos de dados dos novos atributos inclu´ıdos nas classes dos padr˜oes e `a impress˜ao de etiquetas. A vers˜ao 1.0 do GREN (e tamb´em a correspondente vers˜ao do GREN- Wizard) permitia a inclus˜ao de novos atributos nas classes dos padr˜oes, mas apenas quatro tipos de dados eram previstos: n´umero inteiro, n´umero flutuante, data e texto. Ao modelar o sistema de 6CAGNIN, M. I.; MALDONADO, J. C.; PENTEADO, R. D.; GERMANO, F. S. Manutenc¸˜oes no framework GREN e no GREN-Wizard motivadas pelo seu uso no processo de reengenharia de sistemas legados. Documento de trabalho, a ser publicado como Relat´orio T´ecnico do ICMC-USP, 2002.
6.7 Aval. utilidade ling. padr˜oes na inst. de um framework usando seuWizard 153 biblioteca, a aluna percebeu que seria conveniente que o GREN-Wizard apoiasse a implementac¸˜ao dos seguintes tipos de dados:
Lista a partir de uma tabela: ideal para casos nos quais o valor do atributo pode ser obtido em
uma tabela pr´e-existente do sistema ou criada durante a instanciac¸˜ao. Assim, no sistema de oficina eletrˆonica, por exemplo, ´e poss´ıvel criar um atributo propriet´ario na classe que representa o aparelho eletrˆonico consertado. Isso equivale a acrescentar um relacionamento do tipo “muitos para um” entre o aparelho e seu propriet´ario.
Atributo multi-valorado: ideal para casos nos quais o atributo possui diversos valores vindos
de uma tabela pr´e-existente do sistema ou criada durante a instanciac¸˜ao. Isso possibilita que, por exemplo, no sistema de biblioteca, possam ser cadastrados todos os autores de um determinado livro, ou seja, um novo atributoautores ´e acrescentado `a classe Livro, cujos valores s˜ao provenientes da classe Autor. Isso equivale `a inclus˜ao de um relacionamento do tipo “muitos para muitos” entre Livro e Autor.
Lista discreta: esse ´e um caso particular de Lista a partir de uma tabela e que deve ser usado
quando os valores s˜ao fixos. Por exemplo, o estado civil do leitor da biblioteca pode utilizar uma lista discreta com valores pr´e-definidos. Isso tamb´em equivale a criar um relaciona- mento do tipo “muitos para um” entre o leitor e seu estado civil.
Deve-se observar que esses novos tipos de atributos poderiam ser implementados manualmente na nova aplicac¸˜ao, bastando para isso um pouco de experiˆencia com Smalltalk, mas com o apoio do GREN facilita-se ainda mais o processo de instanciac¸˜ao. Al´em disso, o GREN-Wizard tamb´em foi adaptado para incluir esses novos tipos de dados.
A Tabela 6.21 apresenta um resumo quantitativo da manutenc¸˜ao realizada, na qual ´e mostrado o tempo em horas gasto para realizar a manutenc¸˜ao no GREN e no GREN-Wizard, bem como o n´umero de m´etodos e classes criadas, modificadas, etc. ´E poss´ıvel observar que foi empregado um tempo maior na manutenc¸˜ao do GREN em relac¸˜ao ao do GREN-Wizard, apesar de haver menos m´etodos e classes criadas. A justificativa para isso ´e que a aluna iniciou a manutenc¸˜ao pelo GREN e n˜ao conhecia nem a hierarquia de classes do framework e nem a linguagem Smalltalk. Portanto nessa totalizac¸˜ao de tempo est´a embutido o tempo de aprendizado da hierarquia de classes do GREN e do GREN-Wizard e da linguagem de programac¸˜ao Smalltalk.
Ap´os ter realizado a manutenc¸˜ao no framework GREN e no GREN-Wizard, a aluna instanciou os sistemas usando o GREN-Wizard, tendo obtido vinte e trˆes classes no sistema de biblioteca, com cerca de duas mil e setecentas LOC, e dezesseis classes no sistema de oficina eletrˆonica, com aproximadamente trˆes mil e setecentas LOC. Observa-se que o n´umero de LOC no sistema de oficina ´e maior comparado ao sistema de biblioteca, ao contr´ario do n´umero de classes. Isso se