O segundo passo consiste em fazer o mapeamento entre o SARB e o framework GREN, utilizando a documentac¸˜ao do GREN e os resultados do primeiro passo. Conforme j´a explicado na Sec¸˜ao 4.3, a documentac¸˜ao do GREN ´e constitu´ıda de diversas tabelas que mostram, para cada padr˜ao da GRN, as classes correspondentes do GREN a serem especializadas e os m´etodos a serem sobre- postos durante a instanciac¸˜ao. Al´em disso, a documentac¸˜ao do GREN fornece diversos algoritmos que auxiliam na criac¸˜ao de novas classes, adaptac¸˜ao da interface gr´afica com o usu´ario para incluir novos atributos, e programac¸˜ao dos novos menus do sistema. A implementac¸˜ao das classes deve ser feita utilizando o ambiente VisualWorks, para Smalltalk, que ´e a linguagem na qual o GREN est´a implementado.
No algoritmo gen´erico da Sec¸˜ao 4.4.2, estabelece-se que dada uma classe A da nova aplicac¸˜ao, pode ser necess´ario criar classes A1, A2, ..., An, herdando das classes S1, S2, ..., Sndo framework.
No caso do GREN, para a maioria das classes da nova aplicac¸˜ao s˜ao criadas duas classes: uma delas pertence `a camada de neg´ocios e tem o mesmo nome (“A”, no caso) e a outra pertence `a camada de interface com o usu´ario e tem esse mesmo nome, seguido do sufixo “Form”. Por exemplo, a classe Cidadao do SARB ser´a implementada por meio de duas classes: uma referente `a camada de neg´ocios, que ter´a o nome “Cidadao” e outra referente `a camada da GUI, que ter´a o nome “CidadaoForm”.
A identificac¸˜ao dessas classes ´e feita com base no hist´orico dos padr˜oes e variantes utilizados – Tabela 3.1 (TH), na Tabela 4.2 do GREN para identificar as novas classes da camada de neg´ocios do SARB a serem criadas, e na Tabela 4.3 para identificar as novas classes da camada GUI do
4.5 Exemplo – Instanciac¸˜ao do GREN p/ Sist. de Acompanhamento e Reparo de Buracos 78 SARB a serem criadas. O resultado ´e mostrado, parcialmente, na Tabela 4.5 (TC)2. As Tabelas 4.2
e 4.3 s˜ao utilizadas da seguinte forma:
1. Para todas as linhas da tabela TH, fac¸a uma busca na Tabela 4.2 usando como parˆametros as trˆes primeiras colunas da tabela TH. Se a busca tiver sucesso, o conte´udo da quarta coluna da linha resultante ´e a classe do GREN a ser especializada, portanto adicione uma nova linha a TC, na qual a classe da aplicac¸˜ao ´e a quarta coluna de TH, a classe a ser criada tem o mesmo nome da classe da aplicac¸˜ao e a super-classe do GREN ´e a quarta coluna da Tabela 4.2. Por exemplo, no SARB deve-se percorrer a Tabela 3.1 e buscar as linhas correspondentes na Tabela 4.2. Assim, inicia-se pelo padr˜ao n´umero 1, variantedefault, classe Recurso. A
busca tˆem sucesso e retorna a primeira linha da Tabela 4.2. Assim, cria-se em TC uma linha com as seguintes colunas: Buraco, Buraco e Resource (ver linha n´umero 1 da Tabela 4.5). Fazendo o mesmo para as demais linhas da Tabela 3.1, obtˆem-se as demais linhas ´ımpares da Tabela 4.5. Observe que na coluna “Classe a criar” dessa tabela foi anotado o c´odigo de referˆencia da classe, obtido a partir da quinta coluna da Tabela 4.2.
2. Para todas as classes da camada de neg´ocios criadas no item 1, use seu c´odigo de referˆencia para pesquisar a Tabela 4.3. Se o c´odigo de referˆencia n˜ao for encontrado, ent˜ao n˜ao ´e necess´ario criar uma classe de interface gr´afica com o usu´ario para a classe A. Se ele for encontrado, provavelmente ocorrendo mais de uma vez na tabela, ent˜ao as linhas resultantes da tabela devem ser analisadas de acordo com os variantes ou sub-padr˜oes utilizados. O re- sultado ser´a uma nova linha adicionada `a TC, na qual a classe da aplicac¸˜ao ´e a quarta coluna de TH, a classe a ser criada possui o mesmo nome, com o sufixo “Form” (ou outro sufixo significativo), e a super-classe do GREN ´e a quarta coluna da Tabela 4.3. Por exemplo, se for feita a busca do c´odigo de referˆencia N1 na Tabela 4.3, ser˜ao recuperadas quatro linhas. Como o variante utilizado para quantificar o Buraco foi “Recurso Simples”, ent˜ao a classe da camada GUI do GREN a ser usada como super-classe de BuracoForm ´e a classe Single-
ResourceForm. Assim, a linha 2 da Tabela 4.5 ´e obtida. Usando esse mesmo racioc´ınio s˜ao
obtidas as demais linhas pares da Tabela 4.5.
Ainda no segundo passo da instanciac¸˜ao do SARB, ´e necess´ario examinar as classes criadas e consultar a documentac¸˜ao do GREN para definir os m´etodos a serem sobrepostos (nomes e conte´udos). Por exemplo, a Tabela 4.4 mostra uma pequena parte da tabela do GREN respons´avel por esse mapeamento. Essa tabela deve ser utilizada da seguinte forma:
2
Foi acrescentada uma coluna `a esquerda dessa tabela para numerar suas linhas, a fim de facilitar a explicac¸˜ao de seu conte´udo no decorrer do texto
4.5 Exemplo – Instanciac¸˜ao do GREN p/ Sist. de Acompanhamento e Reparo de Buracos 79
Tabela 4.5: Algumas classes a serem criadas no SARB (TC)
Linha no
Classe da Aplicac¸˜ao Classe a criar Super-classe do GREN Atributos adicionais
1 Buraco Buraco (N1) Resource 2 Buraco BuracoForm SingleResourceForm
3 Tamanho Tamanho (N2) SimpleType prioridadeReparo 4 Tamanho SizeForm StaticObjectForm
5 Ordem de Servic¸o OrdemDeServico (N21) ResourceMaintenance numeroDePessoasEquipe 6 Ordem de Servic¸o OrdemDeServicoForm OneResourceMaintWPWTForm
7 Cidad˜ao Cidadao (N14) DestinationParty endereco, telefone 8 Cidad˜ao CidadaoForm DestinationPartyForm
• A primeira coluna dessa tabela cont´em o nome de uma classe abstrata do GREN, isto ´e, uma classe que possui m´etodos que devem ser sobrepostos por quaisquer classes descendentes. Chamemos essa classe de X.
• Para cada classe do SARB, verifique se a classe X faz parte de sua hierarquia. Em caso positivo, analise cada um dos m´etodos da classe X (segunda coluna da Tabela 4.4) para verificar se ´e necess´ario sobrepor esse m´etodo ou n˜ao (examine o coment´ario da quarta coluna para descobrir isso).
• Caso encontre um m´etodo a ser sobreposto, a quarta coluna da Tabela 4.4 fornece informa- c¸˜oes sobre como codificar tal m´etodo.
A Figura 4.10 mostra parte da hierarquia de classes do GREN, usando a notac¸˜ao UML-F (Fontoura et al., 2001). Classes que cont´em m´etodos-gancho s˜ao classes abstratas, pois esses m´etodos devem ser sobrepostos pelas classes descendentes (note que eles aparecem na Tabela 4.4). Na verdade, alguns desses m´etodos s˜ao opcionalmente sobrepostos, dependendo do uso do framework. Por exemplo, o m´etodohasSourcePartyda classe abstrata BusinessResourceTran-
saction deve ser sobreposto obrigatoriamente, enquanto o m´etodo sourcePartyClass ´e opcio- nal, dependendo se o participante Origem do padr˜ao MANTER O RECURSO(Figura 3.5) foi usado. Decidiu-se criar a Tabela 4.4 para mostrar esse mapeamento e explicar mais detalhadamente o uso dos m´etodos, pois o GREN (e outros frameworks tamb´em) possui uma quantidade muito grande de m´etodos-gancho, o que originaria diagramas complexos de serem entendidos.