Evaluering av klassifikasjonsresultatene

Encerrado o projeto do framework, a pr´oxima atividade a ser conduzida ´e sua implementac¸˜ao (Passo 2.3 da Figura 8.3), constitu´ıda de dois sub-passos, ilustrados na Figura 8.7: implementac¸˜ao das classes em uma linguagem de programac¸˜ao espec´ıfica e documentac¸˜ao do mapeamento entre a linguagem de padr˜oes e o framework.

No primeiro sub-passo as classes do framework, definidas pelo modelo de projeto obtido no passo anterior, s˜ao implementadas usando uma linguagem de programac¸˜ao espec´ıfica. A lingua- gem de padr˜oes fornece o apoio necess´ario ao programador, quando surgirem d´uvidas quanto `a funcionalidade das classes participantes, j´a que ela ´e uma fonte excelente de informac¸˜ao sobre o dom´ınio. Outras decis˜oes espec´ıficas sobre a implementac¸˜ao do sistema devem ser tomadas neste passo como, por exemplo, a escolha das estruturas de dados, a escolha dos tipos de dispositivos

4.2 O Processo de Construc¸˜ao 66 Diretrizes propostas Framework Linguagem de Padrões Linguagens de Programação/ Ferramentas Modelo de Projeto do Framework "Cookbook" Ferramentas de Documentação Decisões de Implementação Implementação das classes do Framework Passo 2.3.1 Passo 2.3.2 Documentação do Framework

Figura 4.5: Implementac¸˜ao do Framework

utilizados para entrada de dados na interface gr´afica com o usu´ario e o estilo dos relat´orios do sistema. O resultado deste passo ´e o c´odigo do framework.

Ressalta-se, aqui, que este sub-passo pode ser bastante complexo, dependendo da arquitetura de software definida no passo anterior. Componentes de software ou bibliotecas de classes podem ser reusadas de outros projetos. Al´em disso, ferramentas de Engenharia de Software podem facilitar a execuc¸˜ao deste sub-passo.

A linguagem de padr˜oes pode ser utilizada para guiar a implementac¸˜ao do framework de forma incremental. Cada padr˜ao pode ser considerado como uma unidade funcional, de maneira que a implementac¸˜ao pode comec¸ar pelo primeiro padr˜ao e prosseguir com os demais padr˜oes at´e que todo o framework esteja implementado. Todavia, isso n˜ao ´e sempre trivial de se fazer: durante a fase de projeto (passo 2.2), as classes participantes de cada padr˜ao podem ter sido decompostas e especializadas. Al´em disso, o modelo de projeto do framework pode conter classes que participam de diversos padr˜oes ao mesmo tempo. Torna-se necess´ario, ent˜ao, implementar essas classes de forma parcial, ou seja, implementar apenas os atributos e m´etodos relativos `a funcionalidade espe- rada para o padr˜ao sendo implementado. Portanto, os padr˜oes devem ser estudados previamente e deve ser estabelecida uma estrat´egia para implementac¸˜ao gradual do sistema.

O segundo sub-passo trata da documentac¸˜ao adequada do framework. As diretrizes fornecidas no processo proposto nesta tese conduzem a uma documentac¸˜ao que fornece o mapeamento da linguagem de padr˜oes para as classes do framework. O prop´osito geral ´e de facilitar a instanciac¸˜ao do framework para aplicac¸˜oes espec´ıficas, de forma que, tendo em m˜aos o hist´orico de padr˜oes e variantes aplicados na modelagem, a documentac¸˜ao do framework fornec¸a meios de identificar quais classes devem ser criadas, bem como quais classes do framework devem ser especializadas para origin´a-las, e quais m´etodos devem ser sobrepostos. Resumindo, usu´arios do framework podem facilmente saber o que deve ser feito em cada parte do framework para obter sua aplicac¸˜ao

4.2 O Processo de Construc¸˜ao 67 espec´ıfica, de acordo com a forma na qual ele usou os padr˜oes da linguagem de padr˜oes para modelar sua aplicac¸˜ao.

Assim, recomenda-se a criac¸˜ao de duas tabelas neste sub-passo: a “Tabela de Mapeamento de Classes” e a “Tabela de Mapeamento de M´etodos”. A primeira tabela estabelece o relacio- namento entre as classes participantes de cada padr˜ao e as classes do framework. Ao instanciar aplicac¸˜oes utilizando um framework caixa branca, desenvolvedores precisam criar classes relativas `a aplicac¸˜ao espec´ıfica, que devem herdar das classes adequadas do framework. De acordo com o processo proposto nesta tese, como a instanciac¸˜ao ´e apoiada pela linguagem de padr˜oes, ent˜ao o de- senvolvedor sabe exatamente quais padr˜oes, variantes ou sub-padr˜oes foram utilizados, bem como os pap´eis desempenhados por cada classe da aplicac¸˜ao no padr˜ao correspondente. Assim, essa tabela deve conter o nome do padr˜ao, o variante ou sub-padr˜ao utilizado, as classes participantes do padr˜ao e as classes correspondentes do framework. Esse mapeamento n˜ao ´e, necessariamente, de um para um, j´a que uma classe que participa de um padr˜ao pode ter sido implementada no framework por meio de diversas classes. Da mesma forma, v´arias classes diferentes da linguagem de padr˜oes podem corresponder a uma ´unica classe do framework. Um exemplo de “Tabela de Mapeamento de Classes” ´e dado na Tabela 4.2 da sec¸˜ao 4.3.

A segunda tabela indica quais m´etodos devem ser sobrepostos nas novas classes criadas. Na verdade, ela documenta os m´etodos-gancho do framework (ver sec¸˜ao 2.2.2), isto ´e, os m´etodos declarados em classes abstratas do framework, para as quais espera-se que o c´odigo (ou parte dele) seja fornecido pelas classes herdeiras. Essa tabela deve ter pelo menos trˆes colunas: a primeira com o nome da super-classe, isto ´e, o nome da classe do framework que possui m´etodos abstratos a serem sobrepostos pelas classes descendentes; a segunda com a assinatura do m´etodo (nome, parˆametros e tipo de retorno); e a terceira com uma descric¸˜ao completa do m´etodo, como sobrepˆo- lo e um exemplo de c´odigo-fonte.

De posse dessas duas tabelas, o desenvolvedor de aplicac¸˜oes que utiliza o framework para ins- tanciar suas aplicac¸˜oes pode descobrir quais classes especializar, sem ter que conhecer e estudar a fundo a hierarquia de classes do framework. Mais do que isso, a forma com que essas informac¸˜oes est˜ao armazenadas permite construir uma ferramenta para automatizar a tarefa de instanciac¸˜ao, que ´e o passo 3 do processo geral proposto (Figura 8.1).