Çöp Depolama Alanları Seçimindeki Kriterler

pela autora. Esses estudos est˜ao descritos detalhadamente no Cap´ıtulo 6, e tamb´em serviram para testar o framework, dessa vez para sistemas que exercitavam outros variantes dos padr˜oes. Diver- sos erros foram encontrados durante os testes e os estudos de caso, que foram corrigidos ora no c´odigo-fonte, ora no “Cookbook do GREN”, ou em ambos, se fosse o caso.

4.4

O Processo de Instanciac¸ ˜ao

A reutilizac¸˜ao de um framework caixa branca ´e feita por meio de heranc¸a. Os requisitos da aplicac¸˜ao a ser instanciada devem ser analisados para descobrir quais s˜ao suas classes e a par- tir de quais classes do framework elas devem ser especializadas. No processo proposto nesta tese, como o framework foi desenvolvido com base em uma linguagem de padr˜oes, a instanciac¸˜ao pode ser por ela guiada. Assim, ´e sugerido o processo de instanciac¸˜ao ilustrado na Figura 8.9. Ele ´e composto de quatro passos, detalhados nas pr´oximas sub-sec¸˜oes: an´alise do sistema, mapeamento entre o modelo de an´alise e o framework, implementac¸˜ao das classes espec´ıficas e teste do sistema resultante. Framework Caixa-branca Documentação do Framework Requisitos de uma Aplicação Específica Sistema Específico Decisões de Implementação Histórico de Padrões e Variantes Aplicados Lista de Decisões de Análise Modelo de Análise com Padrões Linguagem de Padrões Lista de Classes e métodos do sistema Decisões de Projeto Linguagem de Programação Análise do Sistema Mapeamento entre o modelo de análise e o framework Passo 4a.1 Passo 4a.2 Passo 4a.3 Implementação das classes específicas Sistema Específico Estratégia de Teste Ambiente de execução Passo 4a.4 Test e do sistema resultante Documentação do Framework

Figura 4.9: Processo de Instanciac¸˜ao do Framework Caixa branca

4.4.1

An ´alise do Sistema

O primeiro passo para instanciar um framework caixa branca ´e a an´alise do sistema, com base na linguagem de padr˜oes (passo 4a.1 da Figura 8.9). Esse passo ´e explicado detalhadamente na Sec¸˜ao 3.4, que mostra o processo de uso de uma linguagem de padr˜oes para modelagem um sis- tema espec´ıfico no mesmo dom´ınio da linguagem. S˜ao entradas para esse passo o documento de requisitos de um sistema espec´ıfico e a linguagem de padr˜oes. O resultado ´e um modelo de an´alise

4.4 O Processo de Instanciac¸˜ao 75 do sistema, o hist´orico dos padr˜oes e variantes utilizados e uma lista de decis˜oes tomadas quando a linguagem de padr˜oes n˜ao atende a todos os requisitos do sistema.

4.4.2

Mapeamento entre o modelo de an ´alise e o framework

De posse do modelo de an´alise do sistema e do hist´orico de padr˜oes e variantes utilizados, aplica-se ent˜ao o segundo passo do processo geral (passo 4a.2 da Figura 8.9) para produzir o mapeamento entre o modelo de an´alise e as classes do framework. Assume-se que o framework tenha sido documentado de acordo com as diretrizes sugeridas no passo de implementac¸˜ao do framework (ver Sec¸˜ao 4.2.3), ou seja, o relacionamento entre os padr˜oes da linguagem de padr˜oes e as classes do framework deve estar documentado apropriadamente. O resultado deste passo ´e uma lista das classes da aplicac¸˜ao e m´etodos correspondentes a serem implementados.

O procedimento a ser seguido para fazer o mapeamento entre o modelo de an´alise e o fra- mework ´e espec´ıfico de cada par “linguagem de padr˜oes e framework”. O algoritmo gen´erico, fornecido a seguir, cont´em uma abstrac¸˜ao das atividades importantes na realizac¸˜ao desse mapea- mento:

1. Considere o “Hist´orico de Padr˜oes e Variantes Aplicados” criado durante a an´alise do sistema (item 11 da Sec¸˜ao 3.4) que cont´em, para cada padr˜ao aplicado, o variante ou sub-padr˜ao utilizado e os pap´eis desempenhados por cada classe. Seja TH o nome dessa tabela. Para cada linha de TH, seja P o padr˜ao aplicado, V o variante ou sub-padr˜ao utilizado, R a classe participante do padr˜ao e A a classe da aplicac¸˜ao, tal que A desempenha o papel R no padr˜ao P e variante V.

2. Construa uma tabela contendo as classes a serem criadas no novo sistema. Seja TC essa tabela. Ela deve ter quatro colunas: classe da aplicac¸˜ao, classe a criar, super-classe do framework e novos atributos.

3. Para cada linha de TH, encontre, na documentac¸˜ao do framework, as classes que devem ser criadas no novo sistema para a tupla {A, P, V, R}. Como resultado s˜ao obtidos os nomes das novas classes a serem criadas referentes a A, denominadas A₁, A₂, ..., An, bem como as

super-classes do framework das quais elas devem herdar, denominadas S₁, S₂, ..., Sn. Crie

ent˜ao, na tabela TC, “n” linhas, cada qual contendo: A, na primeira coluna; Ai, na segunda

coluna; Si, na terceira coluna; e novos atributos acrescentados `a classe A, na quarta coluna

(tais atributos foram destacados no modelo de an´alise).

4. Finalmente, considere a tabela TC resultante. Para cada linha de TC, examine a documen- tac¸˜ao do framework para identificar quais s˜ao os m´etodos que precisam ser sobrepostos.

4.4 O Processo de Instanciac¸˜ao 76 Defina o conte´udo desses m´etodos. Inclua tamb´em os m´etodos para implementar os novos atributos e operac¸˜oes.

4.4.3

Implementac¸ ˜ao do sistema espec´ıfico

No passo 4a.2 foram definidas todas as classes a serem implementadas na nova aplicac¸˜ao, jun- tamente com seus m´etodos. Nesta sec¸˜ao s˜ao fornecidas sugest˜oes para implementac¸˜ao propri- amente dita dessas classes (passo 4a.3 da Figura 8.9). Deve ser utilizada, na implementac¸˜ao, a mesma linguagem de programac¸˜ao na qual o framework foi implementado. O resultado ´e o c´odigo-fonte das novas classes da aplicac¸˜ao, que deve ser utilizado em conjunto com as classes do framework para compor a nova aplicac¸˜ao. As seguintes recomendac¸˜oes podem ser usadas para guiar a implementac¸˜ao:

1. Inicialmente, crie todas as classes identificadas durante o mapeamento (Sec¸˜ao 4.4.2), assim como os m´etodos correspondentes.

2. Crie os m´etodos set e get (para atribuic¸˜ao e recuperac¸˜ao de valor, respectivamente) para

todos os atributos adicionais das classes (quarta coluna da tabela TC).

3. No caso de sistemas de informac¸˜ao convencionais, ´e comum a existˆencia de uma GUI re- presentando a janela principal da aplicac¸˜ao, juntamente com o menu a ser executado pelo usu´ario final. Esse menu deve conter atalhos para todas as operac¸˜oes do sistema.

4. Implemente outras classes e operac¸˜oes n˜ao previstas no framework. Esta atividade est´a fora do escopo desta tese. Envolve profundo entendimento do framework caixa branca, para que sejam feitas as conex˜oes da nova funcionalidade implementada com a funcionalidade provida pelo framework.

5. Finalmente, compile a nova aplicac¸˜ao.

4.4.4

Teste do sistema resultante

O sistema obtido no passo 4a.3 deve ser testado, tanto para garantir que atende aos requisitos estabelecidos, quanto para verificar se funciona no ambiente do usu´ario final. Embora a etapa de teste esteja fora do escopo desta tese, sugere-se que seja escolhida uma estrat´egia de testes, e que casos de teste sejam elaborados para checar o cumprimento dos requisitos funcionais e n˜ao funcionais. O resultado desejado ´e uma aplicac¸˜ao devidamente testada, que pode ser entregue ao usu´ario final.