Figura 51. Estrutura do elemento Template
A Figura 51 apresenta os detalhes do elemeto Template, que define informações sobre os arquivos templates a serem utilizados durante a geração de código-fonte. O atributo Scope determina se o arquivo template será utilizado a nível de projeto ou a nível de classe. O elemento Owner é responsável por definir o nome da classe ou do projeto associado ao arquivo template. O elemento FileName define onde o arquivo template está fisicamente armazenado. Já os elementos Suffix e FileExtension são utilizados para armazenar características específicas do arquivo de código-fonte gerado a partir do template, como a extensão do arquivo e um sufixo de identificação.
ferramenta, respeitando o princípio de manter a lógica de negócio e o acesso aos dados separado da interface de usuário.
Foi utilizado também o padrão Business Object, que de acordo com Alur, Crupi e Malks (2003, tradução nossa), encapsula e gerencia as regras de negócio, bem como a manipulação e persistência dos dados. Este padrão foi implementado em todas as classes da aplicação que necessitaram realizar validações de regras de negócio e/ou persistir dados.
O padrão DAO que, de acordo com Singh et al (2002, tradução nossa), pode ser utilizado para centralizar e encapsular o acesso a uma fonte de dados, foi utilizado tanto para a obtenção dos metadados dos bancos de dados suportados pela ferramenta quanto para efetuar a persistência e recuperação de dados do projeto em XML. Com isto, torna-se mais simples uma futura alteração no mecanismo de persistência utilizado pela ferramenta, bem como o suporte a novos bancos de dados, já que as únicas alterações necessárias devem ser realizadas na classes DAO.
A utilização do padrão Transfer Object permite a troca de dados entre os objetos DAO e os objetos de negócio, sem que um vínculo direto seja estabelecido entre os mesmos (ALUR; CRUPI;
MALKS, 2003, tradução nossa; CRAWFORD; KAPLAN, 2003, tradução nossa). Por tal motivo, esta padrão foi utilizado na ferramenta, permitindo a transferência de dados entre as camadas da aplicação sem criar um vínculo direto entre os objetos de cada camada.
A Figura 52 apresenta o diagrama de classes UML que demonstra o modelo de implementação da classe Project de acordo com os padrões citados anteriormente. Ressalta-se que a classe Project é representada no diagrama da Figura 52 como ProjectDTO, seguindo o padrão de nomenclatura de classes conforme o padrão de projeto aplicado. Vale lembrar que não apenas a classe Project foi implementada de acordo com este modelo, mas todas as principais classes da aplicação.
Figura 52. Diagrama de classes UML representando a implementação das principais classes
Para implementar o mecanismo de validação das regras de negócio e notificação de violação de tais regras ao usuário, foram utilizados os padrões de projeto Command, Observer e Template Method. Através da utilização de tais padrões, foi possível criar um modelo de validação e notificação sem criar uma dependência explícita entre os objetos da aplicação.
O padrão Command permite solicitar a execução de uma operação sem saber exatamente qual a operação que deve ser executada ou até mesmo sem saber qual o objeto que irá executá-la (GAMMA et al, 1995, tradução nossa). A utilização deste comando permitiu a criação de um conjunto de classes responsáveis pela validação das regras de negócio, onde o objeto solicitante não necessita ter conhecimento sobre o objeto responsável pela validação. Ao receber a solicitação de validação, a ação a ser executada é delegada para o objeto de negócios responsável.
O padrão Observer, também conhecido como o mecanismo denominado Publish/Subscribe, define uma dependência entre objetos de um para muitos, de maneira que quando um objeto altera seu estado, todos os dependentes são notificados e alterados automaticamente (GAMMA et al, 1995, tradução nossa). Este padrão permitiu o envio de notificações à camada de visão sobre as validações realizadas.
Por final foi utilizado o padrão Template Method que, de acordo com Gamma et al (1995, tradução nossa), tem como objetivo definir o esqueleto de um algoritmo, delegando alguns passos do algoritmo para as subclasses. Com isso, as subclasses podem redefinir alguns passos do algoritmo sem alterar a estrutura do mesmo. A utilização deste padrão permitiu receber a
notificação de validação das regras de negócio e avisar os usuários sobre a violação de tais regras.
Para tal, foi criada uma classe base de visão, sendo esta responsável por receber a notificação e executar o algoritmo padrão de aviso ao usuário. Este algoritmo invoca métodos virtuais que são implementados pelas subclasses, delegando a estas a responsabilidade de dar as mensagens corretas ao usuário sobre o problema ocorrido. A Figura 53 mostra o diagrama de classes UML para o mecanismo de validação e notificação implementados na ferramenta.
Figura 53. Diagrama de classes UML representando o mecanismo de validação e notificação de violações nas regras de negócio
Na Figura 53 pode-se verificar que a classe Validator possui uma coleção de objetos Validation, sendo que cada Validation é identificado por um nome e referencia a propriedade de uma classe. Ao ser solicitado para executar uma determinada validação, o objeto Validation dispara o evento Action, e notifica o objeto de negócio responsável sobre a necessidade de executar uma determinada validação. Ao finalizar a validação, o objeto de negócio dispara o evento Validated, notificando a visão sobre o término da validação. Neste momento, o método OnValidated é executado, invocando os métodos BusinessObjectValidated e SetErrorMappings, implementados pelas subclasses da visão. Através do método SetErrorMappings, o sistema apresenta as mensagens de erro usuário de acordo com a regra de negócio que foi violada. Existem ainda outras classes
envolvidas no processo, mas estas foram ignoradas no diagrama de classes pelo fato de não serem de extrema relevância para a solução proposta.
Além dos padrões citados anteriormente, foram utilizados outros padrões como o Composite View, que permite a criação de uma visão composta por vários componentes de visão mais simples.
Um exemplo de utilização deste padrão pode ser observado na tela principal do sistema. Outro padrão utilizado foi o Adapter, que permite converter a interface de uma classe em outra interface esperada por um cliente. Este padrão permitiu transformar várias listas do tipo Dictionary, onde cada elemento da lista é formado por uma classe que possui uma chave de identificação e um valor, em listas simples, formadas apenas por valores, suportadas pelos componentes de interface disponíveis no .NET Framework. Outra utilização para este padrão foi a conversão da interface utilizada por algumas classes da API MyMeta, em uma interface conhecida pela arquitetura adotada para a ferramenta.
4 DESENVOLVIMENTO DA FERRAMENTA
Nesta fase, todos os esforços foram concentrados na implementação da ferramenta, que foi realizada utilizando a linguagem de programação C# e o ambiente de desenvolvimento Microsoft Visual Studio. Para tal, as atividades de implementação foram divididas em quatro etapas, conforme apresentado na seção 4.1. Em seguida, na seção 4.2, descreve-se a ferramenta e suas funcionalidades, e por final a validação da ferramenta demonstrando o funcionamento da mesma.