Projeto e Implementação da Camada de Interface Gráfica do Framework

O projeto e a implementação da camada de interface gráfica do framework GRENJ foram divididos em quatorze iterações. Essas iterações correspondem aos quatorze dos quinze padrões da GRN, uma vez que o terceiro padrão, Armazenar o Recurso, não foi implementado no framework GRENJ, pois a forma com foi implementado o tornou pouco utilizado. Cada iteração contemplou a implementação de um padrão na camada de controle e na de interface gráfica.

A seqüência de escolha dos padrões para serem implementados foi ligeiramente diferente da seqüência indicada pelo número dos padrões da GRN. Após o primeiro, o segundo e o quarto padrões terem sido implementados, o décimo primeiro padrão foi escolhido para ser o próximo. A razão dessa escolha foi que a interface gráfica desses padrões contempla todas as funções principais: montagem de formulários, montagem e inserção de tabelas e painéis nos formulários e efetuação de todas as operações de persistência. Essa seqüência permitiu que os detalhes do projeto fossem definidos com mais antecedência, o que diminuiu a ocorrência de modificações e de re-trabalho. Após

a implementação do décimo primeiro padrão, seguiu-se a ordem a partir do quinto padrão da GRN. A Tabela 4.4 lista as classes construídas em cada iteração nas camadas de controle e de interface gráfica.

Tabela 4.4. Lista das classes construídas para cada padrão da GRN.

# Padrão Camada de Controle Camada de Interface Gráfica

1 1 StaticObjectManager, QualifiableObjectManager StaticFormServlet, QualifiableFormServlet 2 2 ResourceInstanceManager ResInsFormServlet 3 4 BusResTransactionManager, ResourceRentalManager BusResTransFormServlet, ResourceRentalFormServlet 4 11 TransactionItemManager TransItemPanelServlet 5 5 ResourceReservationManager ResourceReservationFormServlet 6 6 BasicNegotiationManager, ResourceTradeManager BasicNegotiationFormServlet, ResourceTradeFormServlet 7 7 BusResQuotationManager, QuotationItemManager BusResQuotFormServlet, QuotItemPanelServlet 8 8 BasicDeliveryManager BasicDeliveryFormServlet 9 9 BasicMaintenanceManager, ResourceMaintenanceManager BasicMaintenanceFormServlet, ResourceMaintenanceFormServlet 10 10 MaintenanceQuotationManager MaintenanceQuotationFormServlet 11 12 PaymentManager, PaymentStrategyManager, CashManager, CheckManager, InvoiceManager, CashOnDeliveryManager, CreditCardManager, MoneyOrderManager, EletronicTransferManager PaymentPanelServlet 12 13 TransactionExecutorManager TransactionExecutorFormServlet 13 14 MaintenanceTaskManager MaintenanceTaskPanelServlet

14 15 PartManager, MaintenancePartManager PartFormServlet,

MaintenancePartPanelServlet

A forma de criação da lista de casos de testes, escrita dos testes, implementação das classes e execução dos testes foi a mesma da aplicada no projeto e na implementação do framework Guiwe, que foram descritos na Seção 4.2.2. Entretanto, no framework GRENJ, a implementação de cada padrão implicou na construção de, pelo menos, duas classes, uma na camada de controle e outra na camada de Interface gráfica. Assim, havia uma lista de casos de testes para cada classe a ser implementada dentro de uma iteração.

Como uma classe pode ser estendida por várias outras, o formulário dessa classe pode ser utilizado por suas subclasses. Por exemplo, a classe QualifiableFormServlet pode ser utilizada para montar formulários paras as classes SimpleType e NestedType, que são subclasses de QualifiableObject. De fato, as classes PersistentFormServlet e

negócios. Contudo, isso não é aconselhável porque as demais classes da camada de interface gráfica foram construídas para contemplar as características específicas das classes da camada de negócios e, assim, reduzir o esforço do desenvolvedor durante o desenvolvimento de um sistema baseado no framework GRENJ. Por exemplo, a classe

ResInsFormServlet permite construir um formulário que já contém os campos relativos

aos atributos da classe ResourceInstance e o desenvolvedor não precisa adicionar instruções em sua subclasse para que isso ocorra.

Na camada de controle, entretanto, não é possível utilizar a classe

PersistentObjectManager para tratar de objetos das subclasses de PersistentObject. Os

atributos das subclasses da camada de negócios tiveram que ser tratados individualmente em cada nível da hierarquia de classes para que seus valores pudessem ser atualizados ou obtidos em tempo de execução. Além disso, muitas classes possuem particularidades que necessitavam de métodos extras para que fossem contempladas. Um exemplo dessas particularidades são as diferentes estratégias de pagamento associadas com a classe Payment da camada de negócios. A classe PaymentManager possui métodos específicos para tratar da configuração dessas estratégias. Outro exemplo está na associação entre os recursos e seus tipos, implementada na classe

QualifiableObject por meio de métodos que indicam quais são as classes dos tipos de

recursos. QualifiableObjectManager precisa acessar esses métodos para poder configurar os dados dos tipos dos recursos.

Para exemplificar como é realizada a manipulação de objetos das classes da camada de negócios de um sistema instanciado com base no framework GRENJ, considere uma classe Cliente que estende DestinationParty que, por sua vez, estende

StaticObject. Cliente possui os atributos cpf e telefone, além de idCode e de description

que são herdados indiretamente de StaticObject, como mostra a Figura 4.12 (a). Como

DestinationParty não possui atributos, nem outro tipo de particularidade, não existe um manager específico para essa classe. Assim, StaticObjectManager é utilizada para

manipular objetos da classe Cliente. A Figura 4.12(b) ilustra os passos para a criação de um objeto da classe Cliente e para a atribuição de seus valores na seguinte ordem: 1) um objeto de StaticObjectManager recebe uma mensagem com o nome da classe Cliente e os nomes e os valores de seus atributos; 2) o objeto de StaticObjectManager cria um objeto da classe Cliente com os atributos sem valor; 3) o objeto de StaticObjectManager atribui os valores aos atributos idCode e description, provenientes da classe

StaticObject, por meio de seu método setFields; 4) o objeto de StaticObjectManager usa

o método setFields de sua superclasse ObjectManager para atribuir os valores dos atributos cpf e telefone da classe Cliente.

Figura 4.12. Exemplo de manipulação de um objeto da classe Cliente.