atividade-7

(1)

Universidade Federal de Pernambuco

Centro de Informática

Disciplina:

Tópicos Avançados em Engenharia de Software

Professor:

Paulo Henrique Monteiro Borba

Atividade

Transformação de programas e geração de código

Equipe:

• Filipe Wanderley Lima

• Maria Carolina Revoredo Martiniano

Universidade Federal de Pernambuco

Tópicos Avançados em Engenharia de Software (IF722) Paulo Henrique Monteiro Borba (phmb@cin.ufpe.br)

Atividade 7

Transformação de programas e geração de código

Filipe Wanderley Lima (fwl@cin.ufpe.br);

Maria Carolina Revoredo Martiniano (mcrm2@cin.ufpe.br).

Recife, 8 de novembro de 2010

(2)

1 Controle de Versões

Versão

Data

Descrição

Autor (es)

1.0 03/11/2010 Elaboração do documento. fwl e mcrm2

(3)

2 Sumário

1. Atividades ... 3

2. Velocity ... 4

2.1. Usando o Velocity como pré-processador... 4

2.2. Usando o Velocity como renderizador ... 6

3. Templates do Eclipse ... 7

4. AOM ... 10

4.1. Aplicando o padrão de projeto Type Object ... 12

4.2. Aplicando o padrão de projeto Property ... 13

(4)

3

1. Atividades

Refatorar o sistema escolhido de forma a aumentar o reuso de conceitos, e conseqüentemente a produtividade dos desenvolvedores, com a geração de código usando duas das técnicas mencionadas, registrar:

a) Código anterior e posterior ao refactoring; b) Técnica utilizada e justificativa para seu uso.

(5)

4

2. Velocity

2.1. Usando o Velocity como pré-processador

O Velocity foi usado como um pré-processador para implementar a funcionalidade opcional de registro de visitantes ao grupo de pesquisa nos arquivos onde o Antenna não funciona.

Ao contrário do Antenna, que só funciona em arquivos de extensão java, o Velocity pode ser usado em qualquer tipo de arquivo ou texto.

Com ele foi criado três arquivos templates:

1) create_tables_mysql.vm, que gera o script SQL responsável por criar as tabelas do banco de dados. Uma condição foi colocada para caso a feature de visitantes estiver ativada, ele também criar a tabela visitante.

O arquivo template create_tables_mysql.vm

#if ($visitante)

CREATE TABLE visitante (

idVisitante INT(10) UNSIGNED NOT NULL AUTO_INCREMENT, dataVisita DATE NOT NULL,

dataVolta DATE NOT NULL, FK_membro INT(10) NOT NULL,

FOREIGN KEY (FK_membro) REFERENCES membro(idMembro) ON DELETE CASCADE, PRIMARY KEY (idVisitante)

); #end

2) cadastrar_membro.vm, que é o JSP responsável por cadastrar membros do grupo de pesquisa. Uma condição foi colocada para caso a feature de visitantes estiver ativado, inserir na página a opção de cadastrar um visitante.

O arquivo template cadastrar_membro.vm

...

<option value="professor"><%= ... %></option> <option value="pesquisador"><%= ... %></option> #if ($visitante)

<option value="visitante" ... %></option> #end

(6)

5

3) cronograma_visitas.vm, que é o JSP responsável por exibir o cronograma com as datas dos visitantes do grupo. Uma condição foi colocada para caso a feature de visitantes estiver ativado, inserir todo o código responsável por criar o cronograma.

O arquivo template cronograma_visitas.vm

#if ($visitante)

<%

Fachada fachada = Fachada.obterInstancia();

List<Visitante> visitantes = fachada.listarVisitantes();

%>

<table> ... #end

4) menu.vm, que é responsável por exibir os menus nos cabeçalhos das páginas JSP. Uma condição foi colocada para caso a feature de visitantes estiver ativado, inserir o menu do cronograma de visitas.

O arquivo template menu.vm

<ul>

<li><a href=”index.jsp”>Home</a></li> #if ($visitante)

<li><a href=”cronograma_visitas.jsp”>Cronograma</a></li> #end

... </ul>

Para gerar os arquivos foi criada a classe Velocity no pacote util do projeto. Usando o Antenna para ativar ou desativar a variável booleana visitante. Conseqüentemente a variável era passada ao objeto VelocityContext, responsável por mapear os dados usados nos templates.

O arquivo Velocity.java, responsável por gerar os arquivos dos templates.

...

boolean visitante = false; // #if visitante

visitante = true; // #endif

VelocityContext context = new VelocityContext(); context.put("visitante", visitante);

gerarTemplate(context,

(TEMPLATES_DIR + CREATE_TABLES_MYSQL), (CREATE_TABLES_MYSQL + ".sql"));

(7)

6

2.2. Usando o Velocity como renderizador

O Velocity também foi usado para desacoplar a lógica da apresentação dos dados.

O template do JSP que exibe o cronograma de visitas foi alterado para remover o uso da Fachada.

O arquivo template cronograma_visitas.vm antes

...

<%

Fachada fachada = Fachada.obterInstancia();

List<Visitante> visitantes = fachada.listarVisitantes(); %>

...

<% for (Visitante visitante : visitantes) { %> <tr> <td><%= visitante.getNomeMembro() %></td> <td><%= visitante.getPais() %></td> <td><%= visitante.getDataVisitaS() %></td> <td><%= visitante.getDataVoltaS() %></td> </tr> <% } %> ...

O arquivo template cronograma_visitas.vm depois

...

#foreach ($visitante in $visitantes) <tr> <td>$visitante.nomeMembro</td> <td>$visitante.pais</td> <td>$visitante.dataVisitaS</td> <td>$visitante.dataVoltaS</td> </tr> #end ...

A lógica passou para a classe HandlerMembro, responsável por atender as requisições relacionadas a parte de membros do sistema. É através do método exibirCronograma, que ele consegue a lista de visitantes cadastrados no sistema e passa esta lista para o contexto do Velocity (VelocityContext). O template é então gerado em tempo de execução do sistema.

Método exibirCronograma da classe HandlerMembro

...

VelocityContext contexto = new VelocityContext();

List<Visitante> visitantes = new ArrayList<Visitante>(); visitantes = fachada.listarVisitantes();

contexto.put("visitantes", visitantes); Velocity.gerarTemplate(contexto,

(Velocity.CRONOGRAMA_VISITAS),

(Configuracoes.raizProjeto + Velocity.WEB_CONTENT_DIR + Velocity.CRONOGRAMA_VISITAS + ".jsp"));

(8)

7

3. Templates do Eclipse

Foram criados alguns templates do Eclipse com o objetivo de automatizar tarefas repetitivas. São eles:

1) Padrão de projeto Singleton

Este padrão de projeto é usado na Fachada para que em todo sistema, apenas exista uma única instância.

Nome: singleton.

Contexto: Java type members.

Template do padrão de projeto Singleton.

private static final ${enclosing_type} INSTANCIA; /**

* Construtor privado. */

private ${enclosing_type}() {

// TODO Construtor gerado automaticamente. }

/**

* Retorna a única instância de ${enclosing_type}. * @return a única instância de ${enclosing_type}. */

public static ${enclosing_type} instancia() {

if (INSTANCIA == null) INSTANCIA = new ${enclosing_type}(); return INSTANCIA;

}

(9)

8

2) Leitor de arquivo

Este template é usado para quando for preciso ler de um arquivo de texto. Nome: lerArquivo.

Contexto: Java.

Template do leitor de arquivo.

${:import(java.io.BufferedReader,

java.io.FileNotFoundException, java.io.FileReader,

java.io.IOException)} BufferedReader entrada = null; try {

entrada = new BufferedReader(new FileReader(${nomeArquivo})); String linha;

while ((linha = entrada.readLine()) != null) {

${processamento}

}

} catch (FileNotFoundException e) { // TODO Tratar exceção. } catch (IOException e) {

// TODO Tratar exceção. } finally {

if (entrada != null) entrada.close(); }

(10)

9

3) Template em branco do JSP

Este template é usado para quando for preciso criar uma nova página JSP. Nome: RGMS JSP Template.

Contexto: New JSP.

Template de uma página em branco JSP.

<%@ page language="java" contentType="text/html; charset=ISO-8859-1"

pageEncoding="ISO-8859-1"%>

<%@ page import="br.ufpe.cin.in980.linhapesquisa.AuxCompilacaoCondicional" %> <%@ page import="br.ufpe.cin.in980.projeto.AuxMenuProjetoPesquisa" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

content="text/html; charset=ISO-8859-1"> <%@ include file="layout/header.rsc" %>

</head> <body>

<img src="img/cin.png" alt="RGS" border="0"

longdesc="index.jsp" /> </a>

</h1>

<%@ include file="layout/menu.rsc" %> </div>

</div>

<div class="chamada-principal"> ${cursor}

</div>

<%@ include file="layout/contato.rsc" %> </div>

<%@ include file="layout/rodape.rsc" %> </body>

(11)

10

4. AOM

O desenvolvimento de um sistema baseado na arquitetura dos AOMs envolve a criação de um metamodelo. Esse metamodelo define como os modelos específicos para o domínio podem ser criados em tempo de execução pelo usuário especialista no domínio.

O metamodelo gerado deve ser implementado através de uma linguagem de programação e funciona como uma máquina instanciadora de objetos, ou seja, ele é capaz de: instanciar os metadados armazenados no banco de dados e refletir mudanças feitas nos metadados, o que significa que se o domínio mudar as mudanças podem ser refletidas na aplicação através da alteração dos metadados. Com isso não se faz necessário realizar o processo de geração de código sempre que mudanças acontecerem no domínio, já que as alterações podem ser realizadas nos modelos armazenados no banco de dados através do metamodelo implementado.

A figura 4.1 mostra os modelos iniciais do domínio do sistema de gerenciamento do grupo de pesquisa. Partindo desse modelo, foram aplicados padrões de projeto que compõem a arquitetura AOM. O processo de transformar um modelo usando padrões de projeto é chamado refactoring baseado em padrões.

(12)

11

Figura 4.1. O modelo inicial de membros e publicações.

(13)

12

4.1. Aplicando o padrão de projeto Type Object

O padrão Type Object separa uma entidade de um tipo de entidade, fazendo com que um número desconhecido de subclasses seja instâncias de uma classe genérica. Ele foi usado para generalizar os tipos de membros e publicações.

Observa-se que, após aplicação deste padrão, as classes TipoMembro e TipoPublicacao

substituíram as classes que representavam variantes, que possuíam o relacionamento de herança com os pontos de variação Membro e Publicacao. O objetivo é permitir a criação de vários tipos de membros e publicações.

Os atributos e métodos comuns a todos os membros e publicações se mantiveram, respectivamente, nas classes Membro e Publicacao. Já os atributos específicos de cada tipo

passaram para as classes TipoMembro e TipoPublicacao.

(14)

13

4.2. Aplicando o padrão de projeto Property

Após a aplicação do padrão de projeto Type Object, objetos de tipos diferentes estarão todos em uma mesma classe, o que significa que é necessário adotar uma forma alternativa para implementar seus atributos. A representação de tipos com atributos diferentes é possível através da aplicação do padrão Property, que cria uma nova classe para representar as propriedades para cada classe entidade, como é mostrado na figura 4.3.

(15)

14

4.3. Aplicando o padrão de projeto Type Square

Com aplicação do padrão de projeto Property resolveu-se o problema de se ter atributos específicos de diferentes tipos de entidades representados na mesma classe. Porém, ainda assim não é possível identificar quais propriedades pertencem a quais tipos de entidades, uma vez que as propriedades estão associadas aos objetos da classe Entidade e não a objetos da classe TipoEntidade.