universidade federal do rio de janeiro aumentando o...

Universidade Federal do Rio de Janeiro

AUMENTANDO O NÍVEL DE ABSTRAÇÃO PARA ETL ATRAVÉS DE MDA

Lúcia Maria Abrunhosa Fernandes

2011



Dissertação de Mestrado apresentada ao

Programa de Pós-graduação em Engenharia de

Sistemas e Computação, COPPE, da

Universidade Federal do Rio de Janeiro, como

parte dos requisitos necessários à obtenção do

título de Mestre em Engenharia de Sistemas e

Computação.

Orientadores: Geraldo Zimbrão da Silva

Rodrigo Salvador Monteiro

Rio de Janeiro

Julho de 2011

iii



DISSERTAÇÃO SUBMETIDA AO CORPO DOCENTE DO INSTITUTO ALBERTO

LUIZ COIMBRA DE PÓS-GRADUAÇÃO E PESQUISA DE ENGENHARIA (COPPE)

DA UNIVERSIDADE FEDERAL DO RIO DE JANEIRO COMO PARTE DOS

REQUISITOS NECESSÁRIOS PARA A OBTENÇÃO DO GRAU DE MESTRE EM

CIÊNCIAS EM ENGENHARIA DE SISTEMAS E COMPUTAÇÃO.

Examinada por:

________________________________________________

Prof. Geraldo Zimbrão da Silva, D. Sc.

________________________________________________

Dr. Rodrigo Salvador Monteiro, D. Sc.

________________________________________________

Prof. Geraldo Bonorino Xexéo, D. Sc.

________________________________________________

Prof. Leonardo Guerreiro Azevedo, D. Sc.

RIO DE JANEIRO, RJ - BRASIL

JULHO DE 2011

iii

Fernandes, Lúcia Maria Abrunhosa

Aumentando o Nível de Abstração para ETL através de

MDA / Lúcia Maria Abrunhosa Fernandes. – Rio de Janeiro:

UFRJ/COPPE, 2011.

XI, 180 p.: il.; 29,7 cm.



Dissertação (mestrado) – UFRJ/ COPPE/ Programa de

Engenharia de Sistemas e Computação, 2011.

Referências Bibliográficas: p. 85-91.

1. Model-driven architecture (MDA). 2. Extract, Transform

and Load (ETL). 3. Data Warehouse (DW). I. Silva, Geraldo

Zimbrão da et al.. II. Universidade Federal do Rio de

Janeiro, COPPE, Programa de Engenharia de Sistemas e

Computação. III. Título.

iv

Agradecimentos Ao meu esposo Dilson e filhos Davi, Daniel e Gabriel, que sempre me estimulam nos

momentos de desânimo. Aos meus pais que me permitiram esta nova jornada.

Ao Professor Geraldo Zimbrão por sua orientação e definição segura do caminho a

seguir.

Ao Professor Rodrigo Salvador por sua co-orientação, paciência e dedicação durante

todo o desenvolvimento deste trabalho.

Aos Professores Geraldo Xexéo e Leonardo Azevedo pela honra de tê-los em minha

banca examinadora.

Aos Professores da Coppe que me deram a oportunidade desta formação,

especialmente ao Professor Jano Moreira.

À Professora Cláudia Werner por seu exemplo de dedicação e entusiasmo durante o

período que pude ser sua aluna.

À MI Montreal Informática Ltda., principalmente à Diretora Adjunta Meri Toledano, que

me estimulou e apoiou nesta empreitada.

A todos que me apoiaram antes e durante o desenvolvimento deste trabalho.

v

Resumo da Dissertação apresentada à COPPE/UFRJ como parte dos requisitos

necessários para a obtenção do grau de Mestre em Ciências (M.Sc.)



Julho/2011



Programa: Engenharia de Sistemas e Computação

A Tecnologia da Informação (TI), desde seu início, sempre teve como objetivo a

extensão da capacidade humana, através da melhoria ou automação de suas

atividades cotidianas. Durante sua evolução uma meta constante tem sido a elevação

do nível de abstração das linguagens de programação. A abordagem MDA (Model

Driven Architecture) surgiu como uma tentativa de alcançar estas metas, favorecendo

o foco no negócio e permitindo a diminuição da preocupação nos detalhes de

implementação. Uma importante área de TI (Tecnologia da Informação) é a gestão

organizacional onde sistemas de apoio à decisão se utilizam de dados operacionais e

fornecem uma visão geral do negócio. A preparação (captura e transformação) desse

ambiente tem um conjunto de características que poderiam ser explorados em uma

abordagem MDA no âmbito dos objetivos originais de TI (abstração, refinamento e

automação). Este trabalho discute como o processo de construção MDA permitiria a

utilização das melhores práticas de implementação ETL mantendo, ao mesmo tempo,

foco no negócio e provendo um nível de abstração adequado.

vi

Abstract of Dissertation presented to COPPE/UFRJ as a partial fulfillment of the

requirements for the degree of Master of Science (M.Sc.)

INCREASING THE ABSTRACTION LEVEL FOR ETL THROUGH MDA


July/2011

Advisors: Geraldo Zimbrão da Silva


Department: Computing and Systems Engineering

Information technology (IT), since its beginning, has always had as its aim the

extension of human capacity through improvement or automation of daily activities.

During its evolution, raising the abstraction level of programming languages has been a

constant goal . The MDA (Model Driven Architecture) approach arose as an attempt to

achieve these wishes: greater focus on the business and reduce of concern on

implementation details. One important area of IT is the organizational management

where decision support systems use operational data and provide a business overview.

The preparation (capture and transformation) of this environment have a set of

characteristics that could be exploited in a MDA approach under the original goals of

IT: abstraction, refinement and automation. This work discusses how MDA construction

process would allow for using best ETL implementation practices and at the same time

keep focus on business providing a suitable abstraction level.

vii

Índice I. INTRODUÇÃO ...................................................................................................... 1

II. CONCEITOS FUNDAMENTAIS ........................................................................... 5

II.1. O software e a Engenharia ............................................................................ 5

II.2. Aumentando o nível de abstração com MDA ................................................. 7

II.3. Contribuição ao MDArte ............................................................................... 11

II.4. Apoiando a Decisão ..................................................................................... 12

II.5. Criando o ambiente DW ............................................................................... 15

II.6. Explorando a Arquitetura Data Warehouse .................................................. 16

III. TRABALHOS RELACIONADOS ...................................................................... 20

III.1. 2002 ........................................................................................................... 20

III.2. 2003 ........................................................................................................... 21

III.3. 2005 ........................................................................................................... 21

III.4. 2006 ........................................................................................................... 23

III.5. 2007 ........................................................................................................... 23

III.6. 2008 ........................................................................................................... 24

III.7. 2009 ........................................................................................................... 26

III.8. 2010 ........................................................................................................... 27

III.9. 2011 ........................................................................................................... 30

III.10. Análise e Posicionamento do Trabalho Atual ............................................ 31

IV. ESPECIFICAÇÃO ............................................................................................ 34

IV.1. Objetivos Específicos ................................................................................. 35

IV.2. Benefícios .................................................................................................. 38

IV.3. Processo Característico das Transformações de Modelo ........................... 40

IV.4. Personalização do Processo de Transformação ......................................... 41

IV.5. Fluxo Básico para Personalização de Cartuchos ........................................ 43

V. PROVA DE CONCEITO .................................................................................... 50

V.1. Premissas ................................................................................................... 50

V.2. Passo 1 (A9): Parâmetros, estereótipos, valores etiquetados e outros. ....... 52

V.3. Passo 2 (A10 e A12): Personalização do Metamodelo ................................ 56

V.4. Passo 3 (A14): Validação ............................................................................ 57

V.5. Passo 4 (A14): A Geração do Código .......................................................... 59

V.6. Passo 5 (A14): Construção do Cartucho ..................................................... 62

V.7. Passo 6 (A15): Criação do Projeto Exemplo ................................................ 62

V.8. Passo 7 (A15): Configuração ETL ............................................................... 63

V.9. Passo 8 (A16 e A17): Modelos OLTP e DW com marcações ...................... 64

viii

V.10. Passo 9 (A16 e A17): A Transformação dos Dados ................................... 72

V.11. Passo 10 (A18 e A19): Análise dos Resultados ......................................... 74

VI. CONSIDERAÇÕES FINAIS .............................................................................. 78

VI.1 MDA ou Ferramentas ETL? ......................................................................... 78

VI.2. Conclusões................................................................................................. 81

VI.3. Trabalhos Futuros ...................................................................................... 83

REFERÊNCIAS BIBLIOGRÁFICAS ...................................................................... 85

APÊNDICE I: METAFACADES ............................................................................. 92

APÊNDICE II: VERIFICAÇÕES E MENSAGENS DE ERRO ................................. 97

APÊNDICE III: PROFILE DE PERSISTÊNCIA .................................................... 106

APÊNDICE IV: MODELOS UML DA POC ........................................................... 123

APÊNDICE V: DESEMPENHO NA CARGA ........................................................ 128

APÊNDICE VI: EXEMPLOS DE MODIFICAÇÕES NO MODELO DE OBJETOS 140

APÊNDICE VII: ARQUIVOS DE ESPECIFICAÇÃO ............................................ 147

1.Cartridge.xml ................................................................................................. 148

2.Metafacades.xml ............................................................................................ 155

3. Namespace.xml ............................................................................................ 158

4.Profile.xml ...................................................................................................... 171

ix

Índice de Figuras Figura 1: Etapas de transformação CIM → PIM → PSM .......................................... 9

Figura 2: Posicionamento do SBVR no processo MDA (OMG, 2008) ..................... 10

Figura 3: Classes da Informação ............................................................................ 13

Figura 4: Componentes básicos de um ambiente DW ............................................ 17

Figura 5: Tipos de tabelas em um Data Warehouse ............................................... 19

Figura 6: Quadrante Mágico para Ferramentas de Integração de Dados ............... 36

Figura 7: Etapas Básicas do Processo de Transformação ..................................... 40

Figura 8: Fluxo com macro-atividades para personalização de cartuchos .............. 43

Figura 9: Sub-processo “Projetar novos requisitos para cartucho” ......................... 44

Figura 10: Sub-processo “Desenvolver transformações de modelo que atendam aos

requisitos” ................................................................................................................... 46

Figura 11: Sub-processo “Modelar Exemplo e Executar Transformações” ............. 47

Figura 12: Processo de Personalização de cartuchos ............................................ 48

Figura 13: Marcações na entidade Clientes ........................................................... 53

Figura 14: Estereótipos e valores etiquetados para os modelos DW e OLTP ......... 54

Figura 15: Opções de valores para a tag AttributeType .......................................... 54

Figura 16: Propriedades globais para o projeto DwEtl no arquivo cartridge.xml ..... 55

Figura 17: Valores para propriedades do projeto DwEtl no andromda.xml ............. 56

Figura 18: Trechos dos metamodelos de classes e de atividades do Hibernate ..... 57

Figura 19: Algumas mensagens de erro ................................................................. 58

Figura 20: Join entre duas tabelas OLTP ............................................................... 59

Figura 21: Carga inicial da tabela de Fato Empréstimos ........................................ 60

Figura 22: Esquema modelo de código para um tipo de carga ............................... 61

Figura 23: Trecho de código correspondente ao esquema modelo ........................ 62

Figura 24 – Valores etiquetados para geração de código ....................................... 63

Figura 25 – Esquema do Processo ETL ................................................................. 64

Figura 26 – Dois modelos de classes ..................................................................... 65

Figura 27 - Marcações no modelo OLTP ................................................................ 66

Figura 28 - Marcações no modelo DW ................................................................... 66

Figura 29 – Parâmetros para o processo de agregação ......................................... 67

Figura 30 – Carga incremental da Dimensão Clientes com Overwrite .................... 68

Figura 31 – Carga incremental da Dimensão Clientes com AddRow ...................... 69

Figura 32 - Fato com carga incremental na opção CursorSequential ..................... 71

Figura 33 – Carga incremental do fato Emprestimos usando CommandDirect ....... 72

Figura 34 – Atividades de Transformação .............................................................. 73

x

Figura 35 – Atividades de Transformação – código ................................................ 74

Figura 36: Exemplo de metamodelo – noções básicas ........................................... 93

Figura 37: Metafacade DwEtlEntityAttribute ........................................................... 94

Figura 38: Estereótipos aplicáveis aos modelos de classes ................................. 107

Figura 39: Valor Etiquetado TimeGranularity e código gerado correspondente .... 110

Figura 40: Trechos de código para CursorSequential e CommandDirect ............. 111

Figura 41: Trechos de código para onExtraction e onTransformation ................... 112

Figura 42: Trechos de código para Overwrite e AddRow...................................... 113

Figura 43: Listas de valores para tagged values .................................................. 114

Figura 44: Preenchimento do valor etiquetado AttributeType ............................... 115

Figura 45: Seleção de elemento para o valor etiquetado tipoCliente .................... 115

Figura 46: Operação de transformação para Saldo_Real ..................................... 117

Figura 47: Processo de transformação para o fato Empréstimos ......................... 118

Figura 48: Estereótipos aplicáveis aos modelos de atividades ............................. 118

Figura 49: Atribuição fixa à coluna tipoCliente ...................................................... 119

Figura 50: Atribuição condicional a Saldo_Real ................................................... 120

Figura 51: Atribuição de cálculo a Saldo_Real ..................................................... 120

Figura 52: Diagramas para Transformação de Dados .......................................... 121

Figura 53: Profile de Persistência ......................................................................... 122

Figura 54: Estrutura básica do modelo de persistência do ambiente OLTP .......... 124

Figura 55: Estrutura básica do modelo de persistência do ambiente DW ............. 124

Figura 56: Modelo de ações aplicáveis à entidade Clientes (DW) ........................ 125

Figura 57: Código correspondente à transformação da coluna tipoCliente. .......... 126

Figura 58: Modelo de ações aplicáveis à entidade Emprestimos (DW) ................ 126

Figura 59: Código correspondente à transformação da coluna Saldo_Real ......... 127

Figura 60: Package de Transformação ................................................................. 127

Figura 61: Modelo de Dados OLTP ...................................................................... 129

Figura 62: Script para carga de dados da tabela Pessoa ..................................... 129

Figura 63: Amostragem de dados da tabela Pessoa ............................................ 130

Figura 64: Amostragem de dados da tabela Cliente ............................................. 130

Figura 65: Amostragem de dados da tabela Agencia ........................................... 130

Figura 66: Amostragem de dados da tabela ContaCorrente ................................. 131

Figura 67: Amostragem de dados da tabela Emprestimo ..................................... 131

Figura 68: Modelo de Dados Data Warehouse ..................................................... 131

Figura 69: Script para carga da base DW ............................................................. 132

Figura 70: Amostragem de dados da tabela Clientes ........................................... 132

Figura 71: Script de carga para Clientes .............................................................. 133

xi

Figura 72: Script de carga para Emprestimo – algoritmo CommandDirect ........... 133

Figura 73: Script de carga para Emprestimo – algoritmo CursorSequential .......... 134

Figura 74: Amostragem de dados da tabela Emprestimos ................................... 135

Figura 75: Características físicas do equipamento usado nos testes ................... 138

Figura 76: SQL*Plus com versão do Oracle ......................................................... 139

Figura 77: Trecho do modelo OLTP antes e depois da modificação ..................... 141

Figura 78: Trecho para carga de Clientes antes e depois da modificação ............ 142

Figura 79: Trecho para carga de Emprestimos antes e depois da modificação .... 142

Figura 80: Segunda modificação no modelo OLTP e trecho do DW afetado ........ 143

Figura 81: Trecho da operação de carga resultante da modificação 2.................. 144

Figura 82: Terceira modificação no modelo OLTP e trecho do DW afetado ......... 145

Figura 83: Trecho da operação de carga resultante da modificação 3.................. 146

1

Capítulo I

INTRODUÇÃO O desenvolvimento do raciocínio humano teve início com sua necessidade de

contar. Esta capacidade e seu desenvolvimento iniciado com a representação

numérica foi um dos fatores que possibilitaram o surgimento da matemática e da

lógica. O ábaco foi um dos primeiros “instrumentos” utilizados para dar suporte a esta

operação (FILHO, 2007). O ser humano, os sistemas numéricos, a matemática e

conseqüentemente a tecnologia tem se desenvolvido chegando ao que conhecemos

hoje como computador, em meados do séc. XX (CONTI, 2010).

Desde o surgimento do computador, sua participação no desenvolvimento da

humanidade tem crescido, expandindo sua atuação e atingindo diferentes áreas. Esta

disseminação da tecnologia tem permanecido razoavelmente constante. Atualmente o

computador pode ser encontrado nos mais diversos locais, tais como hospitais,

bancos, cartões de crédito, automóveis, eletrodomésticos, telefones e, até, nos

primeiros anos escolares. Pode-se concluir, portanto, que a computação (ou

informática), ao longo dos anos, tem se tornado o pilar principal de uma estrutura

constituída por conhecimento e tecnologia, que estende a capacidade humana em

suas diferentes áreas de interesse.

Esta expansão, como era de se esperar, chegou aos altos escalões das empresas.

Isto ocorreu em virtude da constante busca por vantagem competitiva, que poderia ser

traduzida pela busca de conhecimento. Tal necessidade fez com que a informática

2

chegasse aos líderes organizacionais, com a finalidade de fornecer informações que

viessem a suportar um processo decisório consciente e consistente cuja meta seria,

em primeira análise, o retorno do investimento e por fim a sobrevivência da empresa.

Apesar de sua constante atividade de apoio a diversas áreas do desenvolvimento

humano, até a algum tempo atrás, a informática pouco (ou nada) se preocupava em

apoiar seu próprio desenvolvimento. Com o advento da crise do software

(PRESSMAN, 2001) esta situação foi drasticamente alterada e diversos produtos

(chamados de ferramentas de produtividade) foram criados visando apoiar o

desenvolvimento de software, tanto sob o aspecto de velocidade de desenvolvimento

quanto de qualidade do produto gerado.

Neste universo de produtos, a abordagem MDA (Model Driven Architecture) tem

apresentado a possibilidade de orientar o foco do desenvolvimento do software para o

negócio e modelos, permitindo a geração automática de código. O seu maior benefício

está no aumento do nível de abstração no desenvolvimento do software, de forma que

o desenvolvedor deixa de criar um código específico em alguma linguagem para focar

no desenvolvimento de modelos que são específicos para o domínio da aplicação,

mas são independentes da plataforma (LEWIS.& WRAGE, 2004).

Considerando-se ambientes Business Intelligence, observou-se a existência no

mercado de diversas ferramentas ETL (Extract, Transform and Load) capazes de

construir o banco de dados Data Warehouse, no entanto, acreditamos que a utilização

de uma abordagem que traga aumento no nível de abstração e independência de

plataforma possa agregar valor ao desenvolvimento e melhorar sua produtividade.

Desta forma, este trabalho analisa se os benefícios da abordagem MDA podem se

tornar vantajosos para este ambiente (especialmente para sua construção). O objetivo

é analisar, passo a passo, o que pode ser feito, como implementar, vantagens e

desvantagens, possibilidade de desenvolvimento ou expansão, dificuldade e,

finalmente, que resultados podem ser obtidos.

Além da contribuição principal que expõe uma alternativa para o desenvolvimento

de aplicativos ETL através da utilização de MDA, este trabalho também pretende

apresentar algumas outras contribuições paralelas:

3

− A primeira se refere ao rastreamento das etapas necessárias a novas

implementações em cartuchos (MDA), novos ou pré-existentes. O objetivo é

estabelecer um processo padrão que oriente futuros desenvolvimentos.

− A segunda trata da nomenclatura para Data Warehouse (DW) e técnicas

correspondentes, estabelecidas por KIMBALL & ROSS (2002), de tal forma que a

utilização dos conceitos seja fortemente aplicada durante o desenvolvimento do

modelo DW.

− A terceira refere-se à lista que contém as mensagens de erro utilizadas durante a

validação do modelo DW, na qual se poderá observar, mais uma vez, a aderência

ao modelo dimensional e demais preceitos estabelecidos por KIMBALL & ROSS

(2002). E é neste sentido que esta coleção de mensagens se caracteriza como

uma contribuição adicional deste trabalho.

Esta dissertação constitui-se de seis capítulos, além desta introdução, e de sete

apêndices, descritos, resumidamente a seguir:

No Capítulo II, Conceitos Fundamentais, discorre-se sobre os principais

conceitos estudados para o desenvolvimento deste trabalho (MDA – Model Driven

Architecture, DSS – Decision Support Systems e ETL – Extract Transform and Load),

destacando-se suas características e vantagens de uso.

No Capítulo III, Trabalhos Relacionados, serão, brevemente, apresentados

alguns trabalhos que versem tanto sobre MDA quanto ETL objetivando a

contextualização do trabalho atual dentro da comunidade científica.

No Capítulo IV, Especificação, serão estudadas as etapas para desenvolvimento

de um produto visando à geração de código para ambiente ETL. Serão detalhados,

dentre outros, os objetivos principais, requisitos para desenvolvimento e opções de

implementação.

No Capítulo V, Prova de Conceito, seguindo as etapas definidas previamente no

capítulo IV, será apresentada e exemplificada uma prova de conceito, caracterizando-

se por um desenvolvimento dentro de limites pré-estabelecidos capaz de ratificar os

objetivos definidos.

4

No Capítulo VI, Resultados e Conclusões, os resultados do desenvolvimento

serão analisados e as vantagens e desvantagens da abordagem avaliadas. Um

comparativo identificando a aplicabilidade da abordagem proposta versus o uso de

ferramentas ETL de mercado encontra-se no início deste capítulo. Além destes itens

também serão discutidas as possibilidades de implementação e perspectivas futuras.

O Apêndice I (Metafacades) contém os modelos metafacades modificados para

adição das classes necessárias ao desenvolvimento. O Apêndice II (Verificações e

Mensagens de Erro) apresenta todas as mensagens de erro e suas correspondentes

verificações utilizadas na prova de conceito. O Apêndice III (Profile de Persistência)

apresenta o profile de persistência, onde diversos itens foram adicionados para

atender aos objetivos do projeto. O Apêndice IV (Modelos UML da Poc) contém os

modelos de classes utilizados como exemplo para a prova de conceito. O Apêndice V

(Desempenho na Carga) contém o modelo de dados utilizado como exemplo para a

prova de conceito juntamente com um teste realizado para avaliação de desempenho

da carga, de acordo com o algoritmo escolhido. O Apêndice VI (Exemplos de

Modificações no Modelo de Objetos) apresenta um conjunto de alterações

realizadas nos modelos de classes e o impacto no código gerado a partir destas

modificações, considerando-se os modelos originais da Poc. Finalmente, o Apêndice

VII (Arquivos de Especificação) apresenta os arquivos de especificação

(cartridge.xml, metafacades.xml e profile.xml) do cartucho utilizado como base para a

implementação da prova de conceito.

OBS: Os fontes desenvolvidos neste trabalho serão disponibilizados no Portal do

Software Público Brasileiro, no assunto MDARTE cujo endereço se encontra nas

Referências Bibliográficas deste trabalho.

5

Capítulo II

CONCEITOS FUNDAMENTAIS A utilização da tecnologia como um meio de extensão dos sentidos humanos e

aperfeiçoamento de suas capacidades, se materializa através de ferramentas

(softwares) e componentes de hardware mais sofisticados a cada dia. Pode-se dizer

que a tecnologia seria um fazer, tendo como propulsor o raciocínio e os sentidos

(SOUZA, 2008), possuindo vinculação com o desenvolvimento social, econômico e

cultural de sua época (FLUSSER, 2002). No entanto, ela mesma não é o objetivo final.

Desde os primórdios, seu objetivo tem sido o de apoiar, aperfeiçoar e facilitar

atividades executadas pelo ser humano.

II.1. O software e a Engenharia

A informática, enquanto ciência da computação, vem se estruturando, visando

garantir a qualidade e aumentar a produtividade no desenvolvimento do software

(FERNANDES & WERNER, 2009). Nos seus primórdios existiam dois níveis de

linguagem de programação: nível da máquina (onde o código era desenvolvido) e nível

da lógica digital (onde os programas eram executados). Já em 1951 surgiu um terceiro

nível (interpretador) com a função de execução dos programas escritos em linguagem

de máquina (FILHO, 2007).

A partir daí houve um grande desenvolvimento das linguagens de programação e,

efetivamente, de softwares utilizando tais linguagens, no entanto, não havia critérios

6

que orientassem esse processo de desenvolvimento. Isso acabou sendo fatal, como o

revelaram estudos, elaborados na década de 1970, sobre o desenvolvimento de

sistemas: ausência de correção e consistência, baixa qualidade, manutenção

extremamente custosa em função de problemas não detectados por ausência de uma

validação de requisitos mais rigorosa, não reaproveitamento de código, prazos de

implementação não cumpridos em conseqüência de erros ao longo própria fase de

implementação (FILHO, 2007).

Este cenário ficou conhecido como "crise do software" (PRESSMAN, 2001). Em

resposta a este cenário foi criada a disciplina Engenharia de Software que tem a

intenção de dar um tratamento sistemático e controlado ao desenvolvimento de

softwares complexos, além de melhorar a qualidade do software gerado, aumentar a

produtividade e atender aos requisitos de eficácia e eficiência (MAFFEO, 1992).

Ironicamente, não havia até a crise do software, uma preocupação em se automatizar

a própria informática. Foi somente a partir deste momento que a utilização de

softwares para automação de processos de desenvolvimento de software passou a ser

considerado.

Hoje a Engenharia de Software enfrenta desafios ainda maiores que ao tempo de

sua criação, tais como: produtividade (sistemas complexos e com grande número de

tecnologias envolvidas), portabilidade (softwares fortemente ligados às suas

respectivas plataformas), interoperabilidade (a ligação e troca de informações entre

sistemas de diferentes tecnologias e plataformas), documentação (modelos são

independentes do código, tornando qualquer mudança de requisito em modificação da

documentação e do código independentemente) (TRINTA, 2010).

Um aspecto que tem crescido constantemente desde o primeiro código é o

distanciamento entre o código desenvolvido (mais próximo da linguagem humana) e o

gerado (código de máquina). Este distanciamento é chamado de nível de abstração.

As linguagens de baixo nível (p.ex: assembly), mais próximas da linguagem de

máquina deram lugar a linguagens de alto nível, compostas de símbolos mais

complexos, inteligíveis pelo ser humano e não executáveis diretamente pela máquina.

Estes saltos tecnológicos trouxeram significativas modificações na forma de se

codificar. Em cada um deles ocorreu algum ganho (aumento) no nível de abstração.

Seja no afastamento da linguagem da máquina, seja no afastamento da plataforma

(QUEIROZ, 2010).

7

Até alguns anos atrás, o investimento em nível de abstração (aumento da distância

entre o código humano e o código de máquina) era difícil, principalmente por causa do

hardware, uma vez que seu custo tornava indispensável a otimização do software

desenvolvido. Atualmente, este tipo de pressão é menor, pois o custo do hardware

diminuiu consideravelmente em relação ao custo da mão de obra. A preocupação,

então, passou a ser a produtividade. O melhor aproveitamento da mão de obra tornou-

se mais significativo para um projeto que o hardware.

Ultimamente têm surgido conceitos que objetivam um novo salto: a elevação do

nível da solução através da abstração da codificação e evidenciação das regras e

fluxos de negócio. Estes conceitos buscam um melhor aproveitamento do tempo de

concepção e desenvolvimento, privilegiando atividades conceituais como

especificação, modelagem e prototipagem. Com isso tornam o desenvolvimento (ou

mais especificamente, a codificação) mais simples, trazendo como conseqüência a

diminuição da necessidade de especialização e quantidade de mão de obra

(QUEIROZ, 2010). Os principais conceitos nesta área são: Orientação a Aspectos,

Model Driven Architecture (MDA), Ontologias, Wisewig, BPM.

É possível que, em um futuro não muito distante, a programação, como a que

conhecemos hoje, deixe de existir e a informática se concentre apenas no negócio,

deixando as tarefas de desenvolvimento para softwares capazes de gerar o código, a

interface e o banco de dados.

II.2. Aumentando o nível de abstração com MDA

De acordo com KONTIO (2005), MDA (Model Driven Architecture - Arquitetura

Orientada por Modelos) é uma abordagem que propõe, através de sua arquitetura, a

separação entre a especificação do sistema e os detalhes de sua operação, os quais

são inerentes à plataforma usada (de tal forma que as modificações na plataforma não

afetem as aplicações existentes e a lógica de negócio evolua independentemente da

tecnologia).

Isso significa que o foco principal do desenvolvimento com esta abordagem migra

do nível de código para o nível de modelo. Esta abordagem (MDA) foi adotada em

2001 pelo OMG (Object Management Group) como um framework que usa modelos

no desenvolvimento de software (OMG, 2003).

8

A abordagem MDA estabelece uma seqüência de etapas entre a concepção inicial

do software e sua construção final na plataforma desejada (OMG, 2003). Estas etapas

são:

• Especificação de um sistema independentemente da plataforma que o suporte;

• Especificação das plataformas candidatas e determinação da plataforma a ser

utilizada pelo sistema;

• Transformação da especificação do sistema (genérica) para a plataforma

escolhida (específica).

As três principais metas da abordagem MDA são portabilidade, interoperabilidade e

reusabilidade. Para atingir estas metas a arquitetura MDA utiliza três níveis de

modelos: CIM, PIM e PSM.

O nível CIM (Computation Independent Model) utiliza especificações que não

apresentam detalhes da estrutura do sistema. Neste nível o sistema é especificado em

termos de negócio: o que deve ser feito e não, como deve ser feito. De acordo com a

OMG (2003), o usuário do CIM não precisa estar familiarizado com modelos ou

artefatos necessários ao desenvolvimento das funcionalidades para os requisitos

definidos neste nível. O CIM representa o nível mais alto, mais abstrato da

especificação do sistema.

O segundo nível (ou nível intermediário) é o PIM (Platform Independent Model),

onde as operações a serem realizadas pelo sistema são especificadas não se levando

em consideração onde serão construídas. Uma técnica sugerida por OMG (2003) para

a obtenção de independência de plataforma é modelar o sistema para uma

technology-neutral virtual machine (isto é, uma máquina virtual de tecnologia neutra,

sem plataforma definida, onde os serviços necessários ao projeto podem ser definidos

independentemente de qualquer plataforma). Desta forma, o modelo do sistema pode

ser definido para esta plataforma genérica, virtual e, posteriormente, derivado para a

plataforma desejada (OMG, 2003).

O terceiro nível ou PSM (Platform Specific Model) combina as especificações feitas

no PIM com os detalhes de como o sistema usa um tipo particular de plataforma. A

partir da definição do PSM, o código da aplicação pode ser gerado para execução na

plataforma escolhida.

9

A passagem de um modelo para o outro (CIM → PIM → PSM), dentro da

arquitetura MDA obedece a critérios diferenciados. Enquanto a transformação do CIM

em PIM é manual, através de refinamentos da especificação realizada ao nível de

CIM, a transformação do PIM em PSM pode ser feita de forma automática através de

mapeamentos, permitindo que ferramentas realizem esta transformação. A partir deste

ponto a criação de código para a plataforma específica já pode ser realizada.

A figura 1(baseada em MAZÓN et al., 2005), a seguir, representa a seqüência de

etapas de transformação desde uma especificação de negócio até seu código final.

Pode-se observar que o mapeamento do PIM, que permite a transformação

automática para o PSM pode ser reprisado para diferentes plataformas, favorecendo o

desenvolvimento de código de acordo com a necessidade.

Figura 1: Etapas de transformação CIM → PIM → PSM

Através da figura 1 (baseada em MAZÓN et al., 2005) também se pode inferir que a

especificação não é perdida após sua conversão em código. O processo pode ser

reprisado a qualquer momento após o desenvolvimento do sistema, seja para

conversão de plataforma, seja para inclusão, alteração ou exclusão de

funcionalidades. Esta é, verdadeiramente, a promessa MDA, isto é, favorecer a

definição de aplicações e modelos de dados que permitam flexibilidade a longo prazo

10

no que se refere a: implementação, integração, manutenção, teste e simulação (OMG,

2003).

Apesar do processo de passagem do CIM para o PIM ter sido apresentado como

“Transformação Manual”, a OMG (2008) já especificou um conjunto de regras capazes

de tornar esta conversão automática. O padrão SBVR (Semantics of Business

Vocabulary and Business Rules), estabelecido pelo OMG, tem a finalidade de

estabelecer um conjunto de regras para a definição de especificações de negócio de

tal forma que as especificações hoje, desenvolvidas em linguagem natural possam ser

representadas formalmente visando o processamento mecânico (por computador).

Figura 2: Posicionamento do SBVR no processo MDA (OMG, 2008)

Este posicionamento tem duas implicações:

1. O SBVR está focado nas regras e vocabulários de negócios, incluindo

aqueles relevantes para o uso em conjunto com essas regras. Outros

aspectos de modelos de negócios também têm que ser desenvolvidos,

incluindo processos de negócios e organização estrutura, mas estes devem

ser abordados pela OMG em outras iniciativas.

2. Os modelos de negócios, incluindo os modelos que SBVR suporta,

descrevem as empresas e não os sistemas de TI que os suportam.

Na arquitetura MDA, os sistemas de TI são especificados usando modelos

independentes de plataforma (PIMs) e modelos específicos de plataforma (PSMs).

Desta forma, algum direcionamento será necessário para a transformação de modelos

de negócios para PIMs. Tal orientação está fora do escopo de SBVR. Está previsto

11

que a OMG irá garantir que os metamodelos para diferentes aspectos da modelagem

de negócios formem um todo coerente e pretende estabelecer regras visando orientar

o desenvolvimento das transformações do modelo de negócios para PIM

apropriadamente no futuro.

II.3. Contribuição ao MDArte

O MDArte tem como propósito a criação de um novo referencial de software

público, com o uso de tecnologias modernas, redução do custo total dos serviços de

tecnologia da informação e da dependência de soluções proprietárias (MDARTE,

2011).

A solução foi lançada no dia 27 de outubro de 2009 em Brasília, durante a abertura

do Encontro Nacional do Software Público. O MDArte é baseado na Metodologia MDA,

arquitetura dirigida a modelos, e tem como kernel do seu framework a tecnologia

aberta AndroMDA (LASKOSKI, 2011).

Segundo o site de seus desenvolvedores (ANDROMDA, 2011), o AndroMDA é um

framework gerador de código extensível que segue o paradigma MDA. Os modelos em

UML (Unified Modeling Language) podem ser transformados em componentes

portáveis para a plataforma desejada. O AndroMDA é extensível através de cartuchos

possuindo uma série deles já prontos, como Struts, JSF, Spring e Hibernate.

Através da MDA os modelos (de classes, atividades, casos de uso) criados em uma

ferramenta UML de mercado são exportados em um formato padrão XMI (XML

Metadata Interchange) (OMG, 2010), em seguida lidos e analisados pelo cartucho

mais apropriado, que gera o código fonte na plataforma desejada (APACHE, 2009).

Com a abordagem MDA pretende-se a obtenção de uma infra-estrutura voltada

para o desenvolvimento de softwares de governo e disponibilizadas como software

público. Este é o principal objetivo da comunidade MDArte (MDARTE, 2011).

E é neste sentido que este trabalho se alinha, uma vez que utiliza a abordagem

MDA (e o software AndroMDA) para a geração de aplicações ETL (Extract, Transform

and Load) a partir de modelos desenvolvidos em UML. A MDArte compreende um

conjunto de cartuchos AndroMDA com diversas soluções de projeto e arquitetura

incorporadas nos procedimentos de transformação de modelos seguindo a abordagem

12

MDA. Ao término do desenvolvimento deste trabalho a comunidade poderá contar com

mais instrumento para geração de aplicativos no ambiente Business Intelligence

partindo apenas de modelos de alto nível.

II.4. Apoiando a Decisão

A busca constante por vantagem competitiva faz com que os executivos das

empresas estejam, constantemente, analisando suas informações internas (obtidas da

própria empresa) e necessitando de novas para a tomada de decisão.

Atualmente, a importância da informação para as organizações é universalmente

aceita, constituindo senão o mais importante, pelo menos, um dos mais importantes

recursos cuja gestão e aproveitamento estão diretamente relacionados ao sucesso

desejado (TARAPANOFF, 2001).

A utilização da informação no processo decisório, no entanto, não é simples. O

volume de informações e dados recebidos pelas organizações diariamente é muito

grande. Sabe-se que esta quantidade vem crescendo vertiginosamente a cada ano,

chegando mesmo a dobrar a cada cinco anos (OMG, 2003). Para que seja possível a

tomada de decisão acertada, o volume de informações e de dados colocados à

disposição daqueles que decidem deve ser na medida certa (MORESI, 2000). E é aí

que a informática atua como apoio à área executiva da empresa objetivando fornecer

a informação certa na hora certa.

Segundo MORESI (2000) existem quatro classes diferentes de informação: dados,

informação, conhecimento e inteligência. Cada uma destas classes possui diferentes

valores para o processo decisório:

• Dados – compreendem a classe mais baixa de informação, é a informação

bruta, isto é, são sinais que não foram processados ou interpretados de

qualquer forma. Correspondem à matéria-prima a ser utilizada na produção de

informações. Não podem ser fornecidos diretamente aos altos escalões da

empresa.

• Informação – esta classe já compreende dados que passaram por algum tipo de

processamento (formatação, tradução, fusão, impressão e assim por diante).

13

Estas informações, geralmente, são usadas nos escalões inferiores da

organização, onde a necessidade de informação é quantitativa, possibilitando o

desempenho das tarefas do dia a dia. Estão vinculadas à atividade fim da

empresa.

• Conhecimento – neste nível as informações foram avaliadas sobre sua

confiabilidade, sua relevância e sua importância. É obtido pela interpretação e

integração de vários dados e informações. Os insumos provenientes das

diversas fontes são analisados e combinados visando à obtenção do

conhecimento.

• Inteligência – situa-se no nível mais alto desta hierarquia e é composta não

somente por informações. Resulta da síntese do conhecimento, com o uso do

julgamento e da intuição daquele que toma decisões. É o conhecimento

aplicado ao contexto, transformado em oportunidade e vantagem competitiva.

A figura 3, baseada em MORESI (2000), apresenta uma representação

esquemática da “conversão” dos dados inicialmente capturados até atingirem o nível

da inteligência.

Figura 3: Classes da Informação

Esta hierarquia está intimamente associada à própria hierarquia de uma empresa.

O nível mais baixo corresponde à entrada de dados nos diversos sistemas de

14

informação da empresa (p. ex.: o número da nota fiscal, os itens vendidos na nota

fiscal, valor e data da venda etc.). Estes dados são validados, complementados,

organizados e armazenados para servir às áreas operacionais da empresa, que

trabalham com a informação quantitativa, a informação do dia a dia, que permite gerir

o negócio da empresa.

A transformação de informação em conhecimento requer mais do que simples

agrupamento de dados, requer um processo de análise que estabeleça o tipo de

informação a ser fornecida, sua preparação, agregação ou síntese em unidades

inteligíveis e a apresentação de forma compreensível e prática para o nível decisório

da organização (MORESI, 2000).

A necessidade de obtenção de informações qualitativas que permitissem aos altos

escalões usarem a informação interna da empresa para obter uma visão global de seu

negócio causou o desenvolvimento de sistemas que viessem a dar suporte e ajudar na

gestão de decisões estratégicas. Estes sistemas são conhecidos como Sistemas de

Apoio à Decisão (DSS – Decision Support Systems). Nos anos 80 o GARTNER

GROUP (2010) cunhou o termo Business Intelligence (BI), que corresponde a um

conjunto de técnicas, métodos e processos que objetivam transformar dados em

conhecimento para suportar um processo decisório consciente e consistente cuja meta

é a vantagem competitiva, o máximo retorno do investimento e o menor risco.

No processo de desenvolvimento de um projeto de BI (Business Intelligence), a

primeira etapa é uma técnica chamada Modelagem Dimensional (KIMBALL & ROSS,

2002), isto é, a modelagem de uma base de dados capaz de armazenar e fornecer as

informações necessárias à tomada de decisão. Já o local de armazenamento (ou base

de dados) onde são concentradas informações históricas e agregadas para permitir

consultas e análises é chamado de Data Warehouse (DW).

Segundo ELMASRI & NAVATHE (2005), os DWs proporcionam acesso aos dados

para análises complexas, descobertas de conhecimento, facilitando a decisão e

oferecendo suporte às demandas por dados e informações em uma organização. De

acordo com INMON (1992), um Data Warehouse (DW) é uma coleção de dados

orientada por assunto, integrada, variante no tempo e não volátil que tem por objetivo

dar suporte aos processos de tomada de decisão. É uma forma de, apropriadamente,

construir e gerenciar dados oriundos de diversas fontes com o propósito de obter

15

desde uma simples visão de partes, até uma visão global de todo um negócio

(GARDNER, 1998).

A última etapa de um projeto de BI e, talvez a mais difícil, é a tomada de decisão

baseada na consulta das informações coletadas. Tais consultas são realizadas,

normalmente, através de ferramentas especializadas - OLAP (online analytic

processing), mineração de dados (data mining), projeção de cenários e relatórios ad-

hoc.

II.5. Criando o ambiente DW

O estudo contido neste trabalho trata apenas de uma das etapas da construção de

um Data Warehouse chamada ETL (Extract-Transform-Load), cujo objetivo é realizar a

obtenção, preparação e armazenamento de dados oriundos das bases diárias em uma

base dimensional (DW – Data Warehouse).

O modelo dimensional possui não apenas características diferentes de um modelo

diário (normalmente relacional), mas também nomenclatura e objetivos específicos. De

acordo com KIMBALL & ROSS (2002), o modelo dimensional apresenta uma estrutura

simplificada onde uma tabela central, chamada Fato, é ligada a várias tabelas

responsáveis pela descrição dos fatos, chamadas de Dimensão. A agregação é uma

tabela resumo construída a partir de fatos individuais e cujo objetivo é o desempenho

de acesso.

A transferência de dados entre um ambiente diário (OLTP – on-line transaction

processing) e um ambiente DW congrega um conjunto de operações. Segundo

KIMBALL & ROSS (2002), o primeiro passo é a obtenção dos dados do ambiente

original (esta origem pode corresponder a diversas fontes de dados, de acordo com a

organização do ambiente OLTP). A extração significa a leitura e entendimento da

origem dos dados e a transferência destes dados para uma área de tratamento

chamada Staging Area. Uma vez que o dado é extraído, diversas transformações

podem ser realizadas, tais como limpeza (tratamento de elementos desaparecidos,

padronização de formatos, resolução de conflitos de domínios), combinação de dados

oriundos de múltiplas fontes, eliminação de duplicidades e associação a chaves

únicas. A última etapa é carga no ambiente definitivo (DW), onde a alta direção poderá

realizar pesquisas e obter uma visão global de suas informações.

16

Estas etapas são realizadas, basicamente, de duas maneiras: através de

programas (freqüentemente escritos na linguagem procedural do banco de dados) ou

através de sofisticados softwares de mercado (chamados ferramentas ETL) que

requerem o desenvolvimento de modelos específicos para cumprimento desta tarefa.

Este trabalho apresenta uma terceira alternativa, iniciada em FERNANDES, NETO,

FAGUNDES et al. (2010), na qual a partir dos modelos UML (Unified Modeling

Language), principalmente do modelo de classes, são gerados os códigos necessários

às operações de extração, transformação e carga.

II.6. Explorando a Arquitetura Data Warehouse

Neste tópico, utilizando fortemente os preceitos definidos por KIMBALL & ROSS

(2002) descreveremos os componentes da arquitetura Data Warehouse e

estabeleceremos um vocabulário que será utilizado durante todo o desenvolvimento

deste trabalho. Iniciamos este assunto estabelecendo os requisitos básicos para um

Data Warehouse (DW):

1. O Data warehouse deve tornar a informação da organização facilmente

acessível – o conteúdo deve ser intuitivo e óbvio para o usuário de negócio

entender (e não apenas o desenvolvedor), o que implica em legibilidade e

dados identificados de forma significativa. Os usuários devem ser capazes

de realizar operações de combinação e separação de dados, além de obter

tais informações com o mínimo tempo de espera.

2. O Data Warehouse deve apresentar consistentemente as informações da

organização – isto é, ele deve ter credibilidade. O dado, oriundo de diversas

fontes, deve ser cuidadosamente trabalhado, criticado, limpo, corrigido,

padronizado, consolidado e, só então, apresentado para o usuário.

3. O Data Warehouse de ser adaptável e resistente à mudança – isto significa

que mudanças no negócio do cliente devem ser refletidas no DW sem trazer

impacto para os dados previamente armazenados, isto é, sem invalidá-los e

sem modificá-los.

17

4. O data warehouse deve servir como base para a tomada de decisão – deve

conter os dados corretos para apoiar as decisões da organização. Estas

decisões trazem impacto nos negócios e valoriza a utilização do DW.

Considerando-se os requisitos descritos previamente, passaremos a descrever os

componentes de um ambiente warehousing. Na figura 4 (baseada em KIMBALL &

ROSS, 2002), encontramos quatro componentes específicos de um ambiente Data

Warehouse:

Origem de Dados – estes dados são oriundos dos sistemas que capturam as

transações do negócio do cliente. São os dados do dia a dia. Correspondem à

matéria-prima a ser utilizada na produção de informações para o usuário.

Área Intermediária (Data Staging Area) – corresponde a uma área de trabalho, não

acessível pelos usuários, utilizada durante o processo de extração, transformação e

carga.

Figura 4: Componentes básicos de um ambiente DW

Área de Apresentação – é onde os dados são organizados, armazenados e

disponibilizados para consulta direta pelos usuários, ferramentas de relatórios, e

outros aplicativos analíticos. É o Data Warehouse em si. Os dados neste tipo de banco

de dados estão organizados de acordo com o modelo dimensional. Um modelo

dimensional contém a mesma informação que um modelo E-R normalizado, mas os

dados são empacotados em um formato cujo objetivo é a compreensibilidade do

usuário, o desempenho da consulta, e a resistência à mudança. Se a área de

apresentação é baseada em um banco de dados relacional, então estas tabelas

18

modeladas dimensionalmente são organizadas em um formato conhecido como

esquema estrela. A outra possibilidade é a utilização de bancos de dados

dimensionais (não será tratado neste material).

Ferramentas de Acesso a Dados – O último componente importante do ambiente

de Data Warehouse são as ferramentas de acesso a dados, isto é, o conjunto de

recursos que podem ser fornecidos aos usuários de negócios para consultar a área de

apresentação visando análises e decisões. Por definição, todas as ferramentas de

acesso a dados, o fazem na área de apresentação.

A partir deste ponto será apresentada parte do vocabulário dimensional:

− Fato – a tabela de fato é a principal tabela em um modelo dimensional, pois é

onde se armazenam as medidas numéricas de desempenho do negócio. Pode-

se observar na figura 5 (baseada em KIMBALL & ROSS, 2002) que a tabela de

fato Vendas possui diversas chaves (associadas a cada uma de suas

dimensões) e medidas que caracterizam o negócio (quantidade vendida por

cliente-loja-vendedor-período, valor total da venda por cliente-loja-vendedor-

período, percentual de comissão por cliente-loja-vendedor-período). As tabelas

de fato representam relações mxn entre dimensões. Uma linha em uma tabela

de fato representa uma medida. Uma medida é uma linha em uma tabela de

fato. Todas as medidas em uma tabela de fato devem ter a mesma

granularidade (por exemplo, todas as medições devem estar associadas a mês:

quantidade vendida no mês-cliente-loja-vendedor, percentual de comissão no

mês-cliente-loja-vendedor, etc.). Os fatos mais úteis são numéricos e aditivos

(por exemplo: quantidade vendida. Um contra-exemplo seria o percentual de

comissão, que apesar de ser numérico não é aditivo), isto é, podemos adicioná-

los em várias linhas e obter informações agregadas (por exemplo: se somarmos

a quantidade vendida no mês para uma loja por um vendedor, teremos o total

das vendas deste vendedor independentemente do cliente que realizou a

compra. O mesmo não pode ser feito com o % de comissão).

19

Figura 5: Tipos de tabelas em um Data Warehouse

− Dimensão – as tabelas de dimensão estão sempre vinculadas a alguma

tabela de fato. Não possuem vida própria ou independente. Descrevem

os fatos. Contém informações textuais sobre os fatos a que se

relacionam. A dimensão Cliente, apresentada na figura 5 (baseada em

KIMBALL & ROSS, 2002) caracteriza o cliente do fato Vendas, isto é, contém

informações relativas ao cliente que realizou a compra registrada no Fato. As

dimensões possuem chaves simples, sendo que seus atributos, normalmente,

são usados como filtro nas consultas e definem o nível de agregação dos

dados. São a chave que torna o DW utilizável e compreensível. Os melhores

atributos são textuais e discretos.

No Apêndice III apresentamos mais alguns componentes do vocabulário

dimensional, sua utilização no trabalho e o impacto na geração de código.

20

Capítulo III

TRABALHOS RELACIONADOS Neste capítulo serão apresentados, resumidamente, diversos trabalhos

relacionados a Data Warehouse, processo ETL (Extract-Transform-Load) e MDA

(Model Driven Architecture). Estes trabalhos serão apresentados cronologicamente de

acordo com o ano de sua publicação para que seja possível uma noção da evolução

da pesquisa científica na área foco deste trabalho.

Ao término de toda a exposição será analisada a evolução dos trabalhos nesta área

e a contextualização do atual trabalho neste conjunto de estudos desenvolvidos ao

longo dos últimos anos.

III.1. 2002

VASSILIADIS, P., SIMITSIS, A., SKIADOPOULOS, S. no artigo "Conceptual

modeling for ETL processes" estabeleceram como foco o problema da definição de

atividades de ETL e fornecimento de bases formais para sua representação

conceitual. Neste momento, o modelo proposto por eles é conceitual (a) personalizado

para o rastreamento de relações inter-atributos e as respectivas atividades ETL nos

estágios iniciais de projeto DW; (b) enriquecido com uma "paleta" contendo as mais

freqüentes atividades ETL usadas, como, por exemplo, a atribuição de chaves

substitutas (surrogate keys), a verificação de valores nulos etc.; (c) construída de uma

21

maneira personalizável e extensível, para que o designer possa enriquecê-lo de

acordo com seus próprios padrões recorrentes para as atividades ETL.

III.2. 2003

TRUJILLO, J., LUJÁN-MORA, S. neste artigo, intitulado "A UML Based Approach

for Modeling ETL Processes in Data Warehouses", exaltam a complexidade de um

ambiente Data Warehouse e enfatizam a necessidade de desenvolvimento de

processos ETL capazes de produzir dados de qualidade. Observam que, nesta época,

havia pouca pesquisa vinculada à modelagem de processos ETL. Desta forma

apresentam uma abordagem utilizando UML (Unified Modeling Language) para a

modelagem conceitual de processos ETL. Nesta modelagem são mapeadas as

operações mais comuns associadas a ETL, tais como a integração de diferentes

fontes de dados, a transformação entre fonte e atributos de destino, a geração de

chaves substitutas e assim por diante. Um dos pontos importantes da abordagem,

segundo os autores, é a integração do design de processos ETL com o esquema

conceitual DW.

SIMITSIS, A., VASSILIADIS, P. fizeram uma proposta de metodologia para as

primeiras fases do projeto de data warehouse, com o objetivo de traçar uma análise da

estrutura e conteúdo das fontes de dados existentes e seu mapeamento para o

modelo conceitual de um DW no artigo "A Methodology for the Conceptual Modeling of

ETL Processes". Esta metodologia compreende um conjunto de passos que podem

ser resumidos como: identificação das bases destino; mapeamento de atributos entre

os fornecedores e consumidores e, finalmente, marcação de restrições de execução.

III.3. 2005

VASSILIADIS, P., SIMITSIS, A., TERROVITIS, M., SKIADOPOULOS, S. neste

trabalho ("A generic and customizable framework for the design of ETL scenarios") se

aprofundam no projeto lógico de cenários ETL e no fornecimento de uma estrutura

genérica e personalizável com o objetivo de apoiar o modelador DW em sua tarefa.

Eles apresentam um metamodelo customizado para a definição das atividades de ETL

e seguem uma abordagem de fluxo de trabalho, onde a saída de uma determinada

atividade pode ser armazenada persistentemente ou passada para uma atividade

subseqüente. Além disso, empregam uma linguagem de programação de banco de

22

dados declarativa, LDL, para definir a semântica de cada atividade. O metamodelo é

genérico o suficiente para capturar qualquer possível atividade ETL. Visando à

reusabilidade e flexibilidade, construíram uma paleta com as atividades ETL mais

freqüentemente usadas (chamados templates). No artigo também encontramos uma

discussão sobre a mecânica de instanciação de modelo para atividades concretas. Os

conceitos de design apresentados estão sendo implementados em uma ferramenta,

Arktos II, que também é apresentada.

MAZON, J.N., TRUJILLO, J., SERRANO, M., PIATTINI, M. no seu artigo "Applying

MDA to the development of data warehouses" colocam que diferentes abordagens de

modelagem têm sido propostas para superar cada armadilha de projeto no

desenvolvimento das diferentes partes de um sistema Data Warehouse (DW). No

entanto, segundo eles, todas estas propostas correspondem a soluções parciais que

tratam de aspectos isolados do DW e não fornecem designers com um método

integrado e padronizado para projetar todo o DW (processos ETL, fontes de dados, o

repositório de DW e assim por diante). Como a Model Driven Architecture (MDA) é

uma estrutura padrão para desenvolvimento de software que aborda o ciclo de vida

completo passando por concepção, implantação, integração e gerenciamento de

aplicações através de modelos no desenvolvimento de software, neste artigo eles

descrevem como alinhar todo o processo de desenvolvimento DW para toda MDA.

Começam com a definição de uma MDA multidimensional (MD2A) e seguem com uma

abordagem para a aplicação do framework MDA para uma das etapas do

desenvolvimento DW: modelagem multidimensional (MD). Primeiramente apresentam

a descrição de como construir os diferentes artefatos MDA (modelos, por exemplo)

usando extensões da Unified Modeling Language (UML). Em segundo lugar, as

transformações entre os modelos são claramente e formalmente estabelecidas usando

a abordagem Query/View/Transformation (QVT). Finalmente, um exemplo é fornecido

para melhor mostrar como aplicar MDA e suas transformações para a modelagem

multidimensional (MD).

SIMITSIS, A. apresenta-nos o artigo "Mapping Conceptual to Logical Models for

ETL Processes" que descreve o mapeamento do conceitual para o modelo lógico. Em

sua linha de pesquisa anterior ele estava trabalhando em um modelo lógico e

conceitual para processos ETL. Ele inicia o artigo identificando como uma entidade

conceitual é mapeada para uma entidade lógica. Em seguida determina a ordem de

execução dentro do fluxo lógico usando informações adaptadas a partir do modelo

23

conceitual. Finalmente ele apresenta uma metodologia para a transição do conceitual

para o modelo lógico.

III.4. 2006

De acordo com CHOWDHARY, MIHAILA & LEI (2006), os data warehouses

tradicionais são manualmente desenvolvidos a partir de requisitos específicos e

necessidades de análises de dados. Como conseqüência desta abordagem eles

percebem um descompasso entre a definição dos modelos de processo dos negócios

e os dados armazenados em data warehouses como se eles fossem desenvolvidos

manualmente e em isolamento. Desta forma, consideram um desafio a manutenção do

DW em sincronismo com as contínuas modificações dos modelos de processo de

negócio. Em seu artigo "Model Driven Data Warehousing for Business Performance

Management" eles estabelecem uma abordagem MDDW (Model Driven Data

Warehouse) na área do BPM (Business Performance Management), de tal forma que

o MDDW torne-se uma ponte entre os modelos DW e BPM.

Segundo SKOUTAS, D. e SIMITSIS, A., em seu artigo "Designing ETL processes

using semantic web technologies", uma das tarefas mais importantes realizadas nos

estágios iniciais de um projeto data warehouse é a análise da estrutura e conteúdo das

fontes de dados existentes e seu mapeamento para um modelo de dados comum.

Eles observam que estabelecer os mapeamentos apropriados entre os atributos das

fontes de dados e os atributos das tabelas do Data Warehouse é fundamental para a

especificação das transformações necessárias em um fluxo de trabalho ETL. Dizem

ainda, que o modelo de dados selecionado deve ser adequado para facilitar os

esforços de redefinição e revisão, que geralmente ocorrem durante as fases iniciais de

um projeto data warehouse e servir como meio de comunicação entre as partes

envolvidas. Neste artigo eles tecem uma argumentação sobre a utilização de

ontologias para este fim, pois acreditam que constituem um modelo muito apropriado

para este objeto. Em seguida mostram como o uso de ontologias pode permitir que um

alto grau de automação sobre a construção de um projeto de ETL.

III.5. 2007

Os data warehouses (DWs) armazenam informações históricas e agregadas

extraídas de fontes de informação heterogêneas, autônomas e distribuídas, desta

24

forma, torna-se essencial a especificação de medidas de segurança desde os estágios

iniciais do desenvolvimento DW, segundo SOLER, TRUJILLO et al. no artigo "A

Framework for the Development of Secure Data Warehouses based on MDA and QVT"

eles apresentam um framework baseado em MDA (Model Driven Architecture) para o

desenvolvimento seguro de data warehouses, que contempla todas as fases de

desenvolvimento (conceitual, lógico e físico), embutindo medidas de segurança em

todos os níveis.

III.6. 2008

No artigo intitulado "A Mixed Approach for Data Warehouse Conceptual Design with

MDA", ZEPEDA, CELMA & ZATARIN adotam um conjunto de regras de transformação

como mecanismo para a extração de esquemas multidimensionais a partir da

descrição conceitual do banco de dados operacional. O método desenvolvido se inicia

na descrição conceitual do banco de dados operacional, segue com a captura dos

requisitos de DW e termina com um esquema multidimensional conceitual e detalhado.

A solução para esta abordagem remete ao uso de MDA.

Já GLORIO & TRUJILLO em seu artigo "An MDA Approach for the Development of

Spatial Data Warehouses" tratam da implementação da abordagem MDA para o

desenvolvimento de "spatial data warehouses" através de uma extensão para o

modelo dimensional. Eles definem um conjunto de regras de transformação usando

Query / View / Transformation (QVT) que permitem a obtenção de uma representação

lógica e automática.

MAZÓN & TRUJILLO no artigo "An MDA approach for the development of data

warehouses" descrevem como alinhar o processo de desenvolvimento DW com o

framework MDA (Model Driven Architecture). Eles focam o desenvolvimento do

repositório DW, descrevendo como construir diferentes modelos MDA para este

repositório através de uma extensão da UML (Unified Modeling Language) e de CWM

(Common Warehouse Metamodel). A transformação entre modelos também é

estabelecida com o uso de QVT (Query / View / Transformation language).

Em uma tentativa de transformar a gestão de dados de uma empresa rentável,

muitas delas estão buscando a integração e centralização de seus dados através de

data warehousing segundo MATHEW, A.D., MA, L., HARGREAVES, D.J. no artigo "A

25

conceptual data modelling methodology for asset management data warehousing".

Segundo os autores um Data Warehouse permite às empresas transformar dados em

conhecimento, e conhecimento em lucros tangíveis. De acordo com eles um fator-

chave de sucesso de um Data Warehouse está em sua capacidade de integrar dados

de várias fontes através de um modelo de dados unificado. Dentro da gestão de

ativos, vários destes modelos de dados integrados têm sido propostos, porém,

individualmente, eles cobrem apenas um número limitado de áreas dentro dos dados

de gerenciamento de ativos e não são projetados com data warehousing em mente.

No artigo os autores apresentam o processo de desenvolvimento de um novo modelo

de dados para data warehousing conceitual que integra, de forma holística, numerosas

áreas de dados de gestão de ativos. Uma metodologia de modelagem etnográfica

envolve um conjunto diversificado de insumos (incluindo os padrões de modelo de

dados, normas, informações de dados de modelos de sistemas e modelos de

processos de negócios) que descreve os dados da gestão de ativos. As saídas do

processo foram verificadas por mais de 20 especialistas em gestão de ativos e

validados contra quatro estudos de caso.

Em trabalhos anteriores SIMITSIS, A. e VASSILIADIS, P. apresentaram um

framework de modelagem para processos de ETL composto de um modelo conceitual

que lida com os estágios iniciais de um projeto de data warehouse, e um modelo

lógico que lida com a definição de data-centric workflows. No artigo "A method for the

mapping of conceptual designs to logical blueprints for ETL processes", os autores

descrevem o mapeamento do modelo conceitual para o modelo lógico. Primeiro,

identificam como entidades conceituais são mapeados para entidades lógicas. Em

seguida, determinam a ordem de execução do fluxo de trabalho lógico utilizando a

informação adaptada a partir do modelo conceitual. Finalmente, fornecem um método

para a transição do modelo conceitual para o modelo lógico.

Em seu novo trabalho MUÑOZ, L., MAZÓN, J.N., PARDILLO, J. e TRUJILLO, J.

chamam a atenção sobre a importância do processo ETL (extract-transform-load).

Segundo eles os processos ETL desempenham um papel importante na arquitetura de

um data warehouse (DW), pois são responsáveis pela integração de dados de fontes

heterogêneas para o Repositório DW. De acordo com os autores a maioria do

orçamento de um projeto de DW é gasto em projetar esses processos, uma vez que

não são levados em conta nas fases iniciais do projeto, mas, somente, quando o

repositório é implantado. Para superar esta situação, no artigo "Modelling ETL

Processes of Data Warehouses with UML Activity Diagrams" eles propõem utilizar a

26

UML (Unified Modelling language) para modelar conceitualmente a seqüência de

atividades envolvidas em processos de ETL, desde o início do projeto, usando a

diagramas de atividade (ADs). Essa abordagem oferece aos designers uma

modelagem de elementos fácil de usar a fim de captar os aspectos dinâmicos dos

processos de ETL.

III.7. 2009

Data Warehouses (DW) integram diferentes fontes de dados, a fim de fornecer uma

visão multidimensional destas fontes para a tomada de decisão. Para este objetivo, os

processos ETL (Extract-Transform-Load) são responsáveis por extrair dados de fontes

de dados operacionais heterogêneas, realizar sua transformação (conversão, limpeza,

padronização, etc.), e, posteriormente, sua carga no DW. Nos últimos anos, várias

abordagens de modelagem conceitual foram propostas para a concepção de

processos de ETL. Embora essas abordagens sejam muito úteis para documentar

processos de ETL e apoiar as tarefas de designer, essas propostas falham no

fornecimento de mecanismos para realizar um estágio de geração automática de

código. Tal etapa deve ser obrigatória tanto para evitar falhas quanto para economizar

tempo de desenvolvimento na implementação do processo de ETL complexos. Desta

forma, no artigo "Automatic generation of ETL processes from conceptual models"

MUÑOZ, L., MAZÓN, J.N., TRUJILLO, J. definem uma abordagem para a geração

automática de código para processos ETL. Eles alinham a modelagem de processos

de ETL em DW com MDA (Model Driven Architecture) para, formalmente, definir um

conjunto de transformações QVT (Query/View/Transformation).

Segundo ESSAIDI, M. e OSMANI, A. vários frameworks para Data Warehouses

(DW) e processos de engenharia têm sido propostos nos últimos anos. No entanto não

ocorreu um esforço significativo na unificação de ambos em uma abordagem única e

integrada. No artigo "Data Warehouse Development Using MDA and 2TUP" os autores

apresentam um método unificado que integra o Data Warehousing Framework (DWF)

e o Processo de Data Warehousing (DWP). Eles usam MDA (Model Driven

Architecture) para a definição do DWF (data warehousing framework) a fim de

desenvolver o projeto de cada componente em um DW integrado e padrão. Utilizam

ainda o 2 track unified process (2TUP) para definir o DWP (data warehousing process)

a fim de permitir o desenvolvimento iterativo de DWlayers, considerando,

simultaneamente o negócio e os aspectos técnicos do DW.

27

As tecnologias e arquiteturas propostas no contexto de Business Intelligence são

destinadas a atender às necessidades de dispor de uma base sólida para a tomada de

decisões estratégicas nas organizações de hoje. Este processo envolve assumir riscos

e o objetivo fundamental é tentar minimizá-los. No trabalho intitulado "Empleo De Mda

En La Generación De Procesos Etl", HEDMAN, F.A. descreve as características que

devem possuir os sistemas de apoio à decisão para conduzir os dados pelos caminhos

necessários para chegar ao objetivo final, a busca de conhecimento oculto. Este tipo

de arquitetura, geralmente tem como centro ou núcleo um Data Warehouse. Os dados

integrados neste repositório são a matéria-prima de todo o processo, de modo que sua

qualidade é de importância vital. Garantir esta condição é a responsabilidade dos

processos de extração, transformação e carga (ETL). Neste trabalho são

caracterizados os principais aspectos componentes e fases dos processos ETL

considerando-se a necessidade de uso de novos procedimentos para orientação do

ciclo de vida de desenvolvimento e manutenção visando o aumento de produtividade.

Após da análise do estado da arte, este estudo conclui que o uso da modelagem

conceitual baseada em UML em combinação com o paradigma MDA (model-driven

architecture) é uma variante de solução factível a considerar.

III.8. 2010

ESSAIDI, M. e OSMANI, A. em seu artigo intitulado "A Unified Method for

Developing Data Warehouses" explicam que a arquitetura de Data Warehousing

(DWA) é definida através de várias camadas heterogêneas e inter-relacionados. E

ainda, que cada camada contém diferentes componentes, utiliza diferentes

modelagem de perfis, e é dependente de várias tecnologias. Outro ponto comentado

por eles é que os projetos de Data Warehouse (DW) também estão expostos a vários

riscos técnicos e exigem mais conhecimento sobre a base de conhecimento do

negócio, onde estes aspectos aumentam os custos e o tempo de desenvolvimento de

um DW além de tornar seu projeto e construção muito difícil e desafiador. Eles

observam que várias estruturas para projeto de DWs e engenharia de processos têm

sido propostas durante os últimos anos, no entanto, as abordagens orientadas a

framework deixam de fornecer um sistema integrado e uma estrutura padronizada que

aborde todas as camadas do DW. Segundo os autores, a abordagem orientada a

processos também falha em definir um processo de engenharia que enderece todo o

ciclo de desenvolvimento ddo DW de uma forma iterativa e incremental e, ainda,

28

considere tanto os requisitos de negócio quanto os técnicos. Eles também

consideraram que muito esforço tem sido dedicado à unificação dos dois em uma

abordagem única integrada. No artigo em questão eles se propõe a abordar estas

questões propondo um método unificado para o desenvolvimento de DWs que integre

o framework de DW (DWF) com o processo de DW (DWP). Eles se utilizam da

arquitetura MDA (Model-Driven Architecture) para definir seu framework (DWF) e

adaptam o processo 2TUP (2 Track Unified Process) para o desenvolvimento de DWs

usando o processo de transformações MDA para definir o DWP.

No mesmo ano ESSAIDI, M. e OSMANI, A. apresentaram em uma publicação

científica o artigo intitulado "Model driven data warehouse using MDA and 2TUP" que

trata do mesmo assunto apresentado no SIIE.

A fusão de dados é uma parte essencial do processo de construção ETL (Extract-

Transform-Load) durante a construção de um Data Warehouse, de acordo com

HYENSOOK, K., OUSSENA, S., ZHANG, Y. e CLARK, T. Em seu artigo "Automatic

generation of data merging program codes" eles propõem um Data Merging Meta-

model (DMM) e suas transformações em código na forma do modelo orientado a

engenharia. Segundo seus autores, DMM permite a definição de relacionamentos de

entidades em diferentes modelos e seus tipos de fusão ao nível conceitual. As

transformações são formalizadas utilizando-se ATLAS (ATLAS Transformation

Language), o que permite a geração automática de pacotes PL/SQL para a execução

de operações de fusão (merge) em ferramentas ETL comerciais. Segundo os autores,

com esta abordagem, os engenheiros DW são liberados da construção de scripts

repetitivos e complexos e da preocupação de manter a consistência de projeto e sua

implementação.

Segundo PARDILLO, J. , MAZÓN, J.N. e TRUJILLO, J. o desenvolvimento de data

warehouses deve ser impulsionada por modelos conceituais multidimensionais

independente de tecnologia, que são a base para a implementação do esquema do

banco de dados de data warehouse de acordo com uma tecnologia específica. De

acordo com suas pesquisas, a maioria das pesquisas atuais centra-se na derivação

(automática) dos esquemas de base de dados a partir desses modelos conceituais,

mas negligenciam a derivação automática de metadados OLAP de forma integrada

com o esquema do banco de dados. Consideram que esta integração seja muito

importante, uma vez que permite que ferramentas para o usuário final consultem o

esquema de banco de dados do data warehouse corretamente com a conseqüente

29

redução tanto tempo de desenvolvimento quanto seus custos. No trabalho "Designing

OLAP schemata for data warehouses from conceptual models with MDA" eles propõe

uma model-transformation architecture com a qual se pode aplicar um conjunto de

mapeamentos de dados. Esses mapeamentos permitiriam que os designers facilmente

obtivessem vários tipos de metadados OLAP durante a derivação do esquema do

banco de dados a partir do modelo conceitual multidimensional. Neste trabalho eles

também apresentam uma prova de conceito da abordagem implementada na

plataforma Eclipse.

Uma vez que Business Intelligence evolui a partir de decisões estratégicas off-line

para decisões operacionais online, o projeto de operações ETL (extract-transform-

load) tem se tornado cada vez mais complexo. Muitos desafios surgem neste novo

contexto, como por exemplo, sua otimização e modelagem. No artigo "Leveraging

Business Process Models for ETL Design", WILKINSON, K., SIMITSIS, A.,

CASTELLANOS, M. e DAYAL, U. focam no descompasso entre a visão de TI a

respeito da empresa representada por processos ETL e a visão da empresa requerida

pelos gestores e analistas. Os autores propõem o uso de um modelo de processo de

negócio para uma visão conceitual de DW. Eles apresentam como ligar esta visão

conceitual a processos de negócio existentes e como traduzir este ponto de vista

conceitual para uma visão lógica de ETL que pode ser otimizada. Desta forma eles

pretendem conectar os processos de ETL de volta aos seus processos de negócio

subjacentes possibilitando não apenas uma visão de negócio do ETL, mas também

uma visão em tempo real de toda a empresa.

No artigo "GEM Requirement driven Generation of ETL and Multidimensional

Conceptual Designs", MORAL, O.R., SIMITSIS, A. e GAMAZO, A.A. colocam que nas

fases iniciais de um projeto de data warehouse, o principal objetivo é coletar os

requisitos e necessidades do negócio e traduzi-los em um modelo conceitual e

multidimensional apropriado. De um modo geral esta tarefa é realizada manualmente,

através de uma série de entrevistas envolvendo dois diferentes grupos: os analistas de

negócio e os técnicos modeladores. A concepção de um modelo conceitual apropriado

é uma tarefa sujeita a erros, segundo os autores, pois passa por diversas rodadas de

conciliação e redesenhar, até que as necessidades do negócio fiquem satisfeitas. Os

autores também consideram de grande importância para os negócios de uma empresa

que este processo seja facilitado e automatizado. Sendo assim, o objetivo da pesquisa

destes foi fornecer aos modeladores um meio semi-automático para a produção de

modelos conceituais multidimensionais e, também, uma representação conceitual do

30

processo ETL (extract-transform-load) que responde pela orquestração do fluxo de

dados a partir de fontes operacionais para as construções DW. Particularmente, eles

descrevem um método que combina informações sobre as fontes de dados juntamente

com os requisitos de negócio para validação e complementação (se necessário)

destes requisitos produzindo um modelo multidimensional e identificando as

operações ETL necessárias. O método é apresentado em termos referenciais TPC-

DS, mostrando sua aplicabilidade e utilidade.

Neste ano, apresentamos (FERNANDES, L. A., NETO, B. H., FAGUNDES, V.,

ZIMBRÃO, G., SOUZA, J. M., SALVADOR, R.) a primeira parte deste trabalho,

intitulado “Model-driven Architecture Approach for Data Warehouse” no qual são

exemplificadas as primeiras transformações de modelo para ETL. Nesta versão a

análise principal do trabalho era a verificação da real possibilidade de se gerar código

ETL partindo-se apenas dos modelos de dados. Não havia preocupação com a

abstração. Os valores etiquetados “GroupBy”, “OrderBy” e “Filter”, dentre outros

remetem diretamente à linguagem SQL. No entanto, a partir do resultado bastante

promissor das transformações de modelo desenvolvidas, foi possível elevar o nível de

abstração e ajustar a proposta a um patamar mais conceitual, objetivo do atual

trabalho.

III.9. 2011

Nos últimos anos, várias abordagens conceituais têm sido propostas para a

especificação das principais propriedades multidimensionais (MD) do repositório data

warehouse (DW). No entanto, a maioria deles lida com os aspectos isolados da DW e

não fornecem aos designers um método integrado e padrão para projetar o ciclo de

vida do DW (processos ETL, fontes de dados, o repositório de DW e assim por diante).

Algumas abordagens são dependentes de plataformas específicas ou negligenciam

questões importantes no desenvolvimento do ciclo de vida do DW. O processo de

extração, transformação e carga (ETL) desempenha um papel importante na

arquitetura do Data Warehouse porque é o responsável pela integração de dados de

fontes heterogêneas para o repositório DW. Estas colocações foram feitas por

FARHAN, M.S., MARIE, M.E., EL-FANGARY, L.M. e HELMY, Y.K. no artigo "An

Integrated Conceptual Model for Temporal Data Warehouse Security" no qual os

autores propõem um modelo conceitual para atualização do data warehouse através

de "insert", "update" e "delete", usando processos de ETL e considerando os requisitos

31

de segurança DW. Primeiramente o modelo de ETL proposto é baseado em Unified

Modeling Language (UML), que permite a realização da modelagem conceitual de

processos de ETL. Em seguida é estabelecido foco na integração do modelo ETL com

o modelo DW através de MDA (Model Driven Architecture). Resumidamente, o artigo

propõe um modelo conceitual integrado para abordar os requisitos temporais de

segurança de um data warehouse (CMTDWS).

Os dados, em um Data Warehouse (DW), vêm de várias fontes, operacionais ou

tradicionais, e contém informações confidenciais de uma organização que são usadas

como base para a analise do estado e do desenvolvimento de uma organização

visando a tomada de decisão. Estas informações sensíveis precisam de segurança a

fim de evitar que sejam acessíveis por usuários não autorizados. As pesquisas atuais

em data warehouse têm mostrado vários métodos para a proteção dos dados. Estes

métodos são definidos ao nível de negócio, conceitual, lógico e físico. No artigo "A

SURVEY ON CURRENT SECURITY STRATEGIES IN DATA WAREHOUSES", os

autores SAURABH, A.K. e NAGPAL, B. discutem várias destas estratégias.

III.10. Análise e Posicionamento do Trabalho Atual

De acordo com os trabalhos apresentados observamos que a maior preocupação

está relacionada com a representação conceitual dos componentes de um Data

Warehouse (processos ETL e modelo multidimensional - cubo). Esta característica

pode ser vista em 2002 (definição de atividades ETL e fornecimento de bases formais

para sua representação), 2003 (modelagem conceitual de processos ETL com

mapeamento das operações mais comuns e análise da estrutura e conteúdo das

fontes de dados existentes), 2005 (projeto lógico de cenários ETL com fornecimento

de estrutura genérica e personalizável; uso de mda para a modelagem

multidimensional com transformações de modelos através da abordagem qvt e na

metodologia para transição do conceitual para o lógico em processos ETL).

A partir de 2006 encontramos outras abordagens que se preocupam com

segurança e introduzem a utilização de BPM e ontologias, no entanto a modelagem

conceitual continua presente como em 2006 (MDDW-model driven data warehouse

como uma ponte entre os modelos DW e BPM; uso de ontologias nos esforços iniciais

de um projeto dw meio de comunicação entre as partes envolvidas e automação ETL),

em 2007 (framework baseado em MDA para o desenvolvimento seguro de dws), em

2008 (mecanismo para extração de esquemas multidimensionais usando MDA; uso de

32

MDA para o desenvolvimento de Spatial Data Warehouse; desenvolvimento do

repositório DW, usando QVT e MDA; novo modelo de dados para data warehousing

conceitual que contemplando gestão de ativos; mapeamento e transição do modelo

conceitual para o modelo lógico; modelagem conceitual das atividades envolvidas em

processos de ETL usando diagramas de atividades).

Todas estas abordagens, apesar de muito interessantes no estabelecimento de

padrões e documentação visando auxiliar o modelador na implementação de

processos ETL, não dão qualquer solução para a geração automática de código, a

qual economizaria tempo de desenvolvimento e diminuiria a probabilidade de erros no

desenvolvimento de aplicações ETL (MUÑOZ, MAZÓN, TRUJILLO, 2009).

A partir de 2009 surgiram as primeiras tentativas de geração de código, no entanto

outras áreas também foram contempladas, tais como processos ETL, merge de dados

em diferentes modelos e modelos multidimensionais (utilização MDA e QVT para

geração de código a partir do modelo conceitual; MDA para a definição do DWF;

caracterização dos principais aspectos componentes e fases dos processos ETL). Em

2010 ocorreu uma nova abordagem contemplando a geração de código, além de

outras conceituais (método unificado para DW integrando o framework DWF com o

projeto DWP; DMM (data merging metamodel) para definição de relacionamentos

entre entidades em diferentes modelos e seus tipos de fusão ao nível conceitual

gerando pacotes PL/SQL; geração de metadados OLAP durante a derivação do

esquema do banco de dados; uso de processo de negócio para uma visão conceitual

de DW; meio semi-automático para a produção de modelos conceituais

multidimensionais). Já em 2011 as abordagens retornam ao conceitual (Integração do

modelo ETL com o modelo DW através de MDA; métodos para proteção dos dados).

Uma observação a cerca deste capítulo é que de acordo com os diferentes

objetivos estudados nos diversos trabalhos publicados ao longo destes anos, percebe-

se que o foco destes trabalhos é o ambiente Data Warehouse. O meio de atuação

varia, apesar de MDA aparecer em diversos casos como apoio às propostas. No

nosso caso, o principal foco do trabalho está localizado na abordagem MDA; o Data

Warehouse aparece como coadjuvante no processo. A proposta é que usuários de

MDA também tenham facilidade na geração de aplicações no ambiente DW. Esta

diferença de foco é importante que seja frisada, pois reflete a importância maior dada

a características MDA do que ao Data Warehouse, durante todo o trabalho.

33

Em relação à geração de código, este trabalho encontra dois trabalhos mais

próximos (“Automatic generation of ETL processes from conceptual models” de 2009 e

“Automatic generation of data merging program codes” de 2010). No primeiro trabalho

a geração de código ocorre indiretamente através da utilização de uma ferramenta de

mercado (no caso, OWB da Oracle). A proposta, utilizando MDA e QVT, gera um

modelo de transformação de acordo com a ferramenta de mercado e esta, por sua

vez, gera o código correspondente. O segundo trabalho exporta o CWM contendo as

transformações desejadas (definidas através de um Data Merging Meta Model) para

uma ferramenta de mercado que se encarregará do desenvolvimento das aplicações.

Desta forma, ambas as propostas são similares, pois requerem a utilização de uma

ferramenta ETL de mercado para a geração do código. Outro ponto observado nas

propostas é a preocupação principal com a etapa de transformação de dados. A

modelagem enfatiza, explicitamente, operações de merge, grupamento, dentre outras.

No trabalho aqui apresentado toda a definição é feita utilizando o modelo de

classes, ocorre forte preocupação com abstração (não há qualquer utilização de

mecanismos de SQL explicitamente nas especificações), orientação para o

enriquecimento do modelo gerado usando componentes típicos do ambiente data

warehouse e geração completa de código independente de qualquer software de

mercado. Pode-se entender, portanto, que o trabalho atual se encontra consoante com

os demais estudos que visam também à geração de código, no entanto, sua forma de

atuação é diferenciada dos demais na medida em que se torna independente das

atuais ferramentas de mercado gerando o código final a ser aplicado para a realização

das operações propostas.

34

Capítulo IV

ESPECIFICAÇÃO O desenvolvimento de um software para a geração automática de código baseado

unicamente em modelos certamente requer o estabelecimento de objetivos bem

definidos seguido de uma análise detalhada dos benefícios que se deseja alcançar.

Além disso, a opção por MDA, no lugar das atuais ferramentas ETL de mercado, deve

conter características que a tornem interessante e agreguem valor ao resultado

alcançado.

Em relação ao ambiente escolhido (Business Intelligence), observou-se que o

mesmo possui algumas características específicas que o tornam diferenciado:

nomenclatura exclusiva, grandes volumes de dados, necessidades de desempenhos

pontuais, além de contar com uma grande variedade de ferramentas auxiliares. Sendo

assim, este trabalho estudará o que poderia ser agregado ou vantajoso na utilização

de MDA para este ambiente (Business Intelligence, mais especificamente na fase ETL)

e qual a complexidade para este desenvolvimento, tanto do ponto de vista da

implementação do projeto quanto de uso da especificação para geração de código.

Baseado nas observações acima foi definido um conjunto de metas e uma relação

dos principais benefícios desejados. E, para garantir uma concreta avaliação dos

resultados, foi decidida a construção de uma prova de conceito, uma avaliação sobre a

flexibilidade de expansão inerente à MDA (isto é, possibilidade de desenvolvimento de

cartuchos com objetivos específicos) e uma análise da inclusão de novas

35

funcionalidades após o produto gerado (facilidade de ajuste na POC criada para a

inclusão de novas fontes de dados, novas características de desempenho, etc.).

Portanto, neste capítulo serão descritos os requisitos, benefícios e metas, no seguinte

será apresentada a prova de conceito (POC – proof of concept) e nos apêndices V

(Desempenho na Carga) e VI (Exemplo de Modificações no Modelo de Objetos) a

utilização do modelo da Poc para análises de impacto de mudanças nos modelos e

desempenho do código gerado.

IV.1. Objetivos Específicos

A primeira etapa deste trabalho foi estabelecer limites, ou fronteiras bem

demarcadas, uma clara determinação do que fazer e quais os benefícios desejados. O

projeto foi focado, especificamente, na fase ETL (Extract, Transform and Load),

considerada uma das mais importantes etapas no desenvolvimento de um ambiente

de Business Intelligence (BI). Optou-se por estabelecer metas compatíveis com as

características específicas do ambiente, a saber:

A. Nomenclatura distinta

O ambiente Business Intelligence possui terminologia e conceitos específicos

diferenciados do OLTP (Online Transaction Processing) tradicional. Assim, o uso desta

terminologia foi considerado importante para a especificação do modelo e das diversas

parametrizações. No apêndice III se encontra, em detalhes, toda a terminologia

utilizada no trabalho juntamente com o impacto correspondente no código gerado.

B. Grandes Volumes de Dados

Em virtude do grande volume de dados característico do ambiente, a preocupação

com desempenho é uma constante. Entendeu-se que uma solução única de

performance que atendesse a todas as situações não seria possível. Além disso,

considerou-se que a escolha do melhor algoritmo para cada caso devesse ser uma

decisão soberana do modelador, uma vez que as condições não-técnicas (por

exemplo, janela de tempo para a operação, uso exclusivo do banco de dados,

possibilidade de execução simultânea, disponibilidade de memória, tipo de

processador, etc.) poderiam ser mais cruciais do que apenas o volume de dados.

Assim, optou-se pela parametrização de algoritmo que possibilitasse a expansão, ou

seja, um conjunto que permitisse a criação de algoritmos diferentes para situações

específicas, com a possibilidade de adição de novos algoritmos.

36

C. Ampla Variedade de Ferramentas

A etapa de extração, transformação e carga (ETL) tem à sua disposição, várias

ferramentas de mercado que visam à realização das tarefas de extração,

transformação e carga. Naturalmente, espera-se que a abordagem MDA acrescente

valor ao resultado (ou traga alguma vantagem no uso) e não apenas copie as

funcionalidades das ferramentas.

Figura 6: Quadrante Mágico para Ferramentas de Integração de Dados

A figura 6 (GARTNER, 210) apresenta um quadro com os principais fabricantes de

ferramentas para integração de dados do mercado, tais como a Oracle com Oracle

Data Integrator, SAP com SAP NetWeaver Business Warehouse, IBM com InfoSphere

DataStage, Informática com o Informatica PowerCenter e Microsoft com SQL Server

Integration Services. Temos também algumas ferramentas gratuitas tais como o Kettle

(do pacote Pentaho Data Integration), Open Studio (Talend), Clover.ETL (OpenSys) e

Ketl (Kinetic Networks), dentre outras.

Uma vez que MDA está fortemente baseada em modelos e os modelos de ambos

os ambientes (origem e destino) podem estar disponíveis, foram acrescentados quatro

37

novas características a fim de ilustrar a possibilidade de agregação de valor e

extensibilidade:

• Restrição de transferência – verificação ou validação sobre a viabilidade da

transferência de dados entre a origem e o destino;

• Identificação dos relacionamentos disponíveis – verificação e análise dos

relacionamentos disponíveis entre as tabelas do modelo e determinação das

ligações (joins) necessárias à obtenção dos dados;

• Transformações opcionais – utilização opcional da etapa de transformação e

possibilidade de determinação do momento da transformação.

• Carga diferenciada de acordo com o ambiente destino – possibilidade de

definição de diferentes estruturas (layouts) para a área intermediária (data

stage).

Resumidamente, a lista de metas a serem alcançadas na POC (proof of concept)

seria:

1. Semântica nativa do domínio

2. Flexibilidade nos algoritmos de carga

3. Integridade na transferência

4. Identificação dos relacionamentos disponíveis

5. Definição da etapa de transformação de dados somente quando necessário

6. Flexibilidade no modelo de extração e carga

7. Extensibilidade inerente à abordagem

Estas são as metas escolhidas para implementação da POC, uma vez que foram

consideradas mais úteis e com mais benefícios, no entanto, esta lista não tem a

finalidade e muito menos a pretensão de ser exaustiva. Utilizando-se a abordagem

MDA seria possível acrescentar novas metas, à medida que o desenvolvedor

adquirisse novos conhecimentos a partir de peculiaridades do ambiente. A facilidade

de adição de novos recursos é uma característica intrínseca, que também será

analisada neste trabalho.

38

IV.2. Benefícios

Cada uma das metas estabelecidas possui benefícios específicos associados,

descritos a seguir. Na seqüência, será detalhado, um processo MDA característico

juntamente com suas etapas de transformação principais, a fim de se identificar os

pontos que estão sendo modificados para atender às metas estabelecidas. O benefício

principal, garantido pelo uso de MDA, é que o modelador possa se concentrar no

negócio, deixando a responsabilidade de implementação para a ferramenta.

A primeira meta estabelecida neste trabalho, que trata da terminologia,

complementa esse benefício já previsto pela abordagem, uma vez que não são

exigidos novos conhecimentos ao modelador para o desenvolvimento do modelo de

dados. Seu foco continua a ser associado com o negócio e toda a interface MDA usa

seu conhecimento prévio deste negócio para o desenvolvimento da solução. Isso se

traduz em aumento de abstração e da separação do raciocínio sobre o negócio do

raciocínio sobre a codificação, de acordo com os princípios básicos de TI (Tecnologia

da Informação).

Uma preocupação constante ao longo do desenvolvimento foi a possibilidade de

resistência no uso de uma ferramenta geradora de código, quando a performance

fosse importante. Observou-se também que um mesmo algoritmo, dificilmente,

atenderia a todas as situações apresentadas. Desta forma, escolheu-se oferecer a

opção de criação de diferentes algoritmos. Assim, o desenvolvedor poderia adicionar

seu aprendizado em projetos de ETL, criando algoritmos mais adequados a cada

ambiente específico e às suas necessidades. No Apêndice V (Desempenho na Carga)

o modelo DW utilizado na Poc foi carregado através de dois algoritmos gerados por

este trabalho e os tempos de carga foram mensurados como base para futuras

análises de desempenho e escolha de novos algoritmos.

A capacidade de ler ambos os modelos (OLTP e DW) proporcionou a oportunidade

de validação das operações de carga. Quando ocorrem mudanças no ambiente diário

(OLTP) ou no ambiente de destino (DW), a modificação em qualquer dos modelos

poderia trazer inconsistências no código gerado, desta forma, a validação destas

alterações deve ser realizada e uma indicação de possíveis problemas produzida. Isto

permitiria uma antecipação de erros nas operações de carga resultantes. No Apêndice

II (Verificações e Mensagens de Erro) encontra-se a relação de validações

desenvolvidas para a Poc deste trabalho. Muitas outras podem ser adicionadas a fim

39

de tornar a modelagem mais segura e minimizar o risco de erros na implementação de

modificações na modelagem dos ambientes OLTP e DW.

Esta mesma capacidade também pode fornecer informações sobre os

relacionamentos existentes entre as tabelas origem de dados. Assim, quando há mais

de um caminho de acesso disponível, seria possível a escolha dos mais interessantes

para o tipo de carga desejado. No apêndice VI (Exemplos de Modificações no Modelo

de Objetos) é apresentado um passo a passo com modificações na modelagem e

conseqüências no código gerado, demonstrando sua capacidade de adaptação

resultante.

As duas últimas metas abordam o uso da opção de transformação, uma das etapas

da operação ETL. A fase de transformação pode ser feita ou não durante a etapa de

carga e pode ter um impacto maior ou menor no desempenho global da operação.

Assim, seria possível estabelecer regras para a execução das rotinas de

transformação (se houver), de acordo com o layout da data stage optando-se:

• por uma carga mais rápida (sem mudança);

• ou mais completa (com alterações);

Esta flexibilidade daria ao modelador a capacidade de adaptar o código gerado

para as características específicas do ambiente. Além dos benefícios provenientes

desses objetivos específicos, há outros provenientes da própria abordagem MDA,

automaticamente incorporadas, tais como:

• independência de plataforma;

• produtividade;

• interoperabilidade;

• exatidão da documentação;

• possibilidade de personalização;

Entre esses benefícios intrínsecos a possibilidade de personalização permite o

desenvolvimento de um cartucho que lida especificamente com o ambiente ETL, o

qual, por sua vez, pode ser melhorado pelos desenvolvedores, permitindo a contínua

evolução e utilização real da experiência adquirida em projetos anteriores.

40

IV.3. Processo Característico das Transformações de

Modelo

O procedimento seguido pela abordagem MDA para transformar modelos em

código é caracterizada por modelos que definem o sistema e cartuchos que lêem os

modelos, identificam suas especificações e geram os códigos apropriados. Esses

cartuchos ficam disponíveis aos modeladores para que estes possam incorporar

personalizações que venham a agregar algum valor ao seu projeto (por exemplo:

produtividade, boas práticas, e assim por diante).

Quando um modelador cria um projeto MDA, ele deve responder a várias

perguntas, que identificam o tipo de projeto (por exemplo: batch x on-line, web x

cliente/servidor x, tipo de banco de dados, e outros). Estas questões determinam os

cartuchos a serem executados na fase de transformação do modelo e, indiretamente,

o tipo de código gerado. O cartucho, quando lê um modelo, deve encontrar

informações suficientes para a geração de código.

Em UML (Unified Modeling Language), é possível personalizar os modelos padrões

através de extensões UML (FARHAD, 2002), utilizando estereótipos e valores

etiquetados (tagged values). De acordo com BOOCH, RUMBAUGH E JACOBSON

(1998) um estereótipo estende o vocabulário da UML, permitindo a construção de um

novo elemento de modelagem derivado de um elemento já existente, porém, incluindo

as novas necessidades.

A Figura 7 mostra, esquematicamente, as etapas para se criar e executar um

processo de transformação de modelo usando a abordagem MDA.

Figura 7: Etapas Básicas do Processo de Transformação

As marcas incluídas no modelo permitem seu enriquecimento semântico de acordo

com os objetivos previamente estabelecidos. O cartucho a ser desenvolvido deve ser

capaz de encontrar e “entender” estas marcas para realizar as transformações de

modelo de acordo com estas especificações.

41

Assim, a qualquer momento, novas marcações podem estar disponíveis para uso

em modelos, permitindo novas semânticas características dos conceitos introduzidos

(DW, por exemplo) e, conseqüentemente, permitindo novas personalizações. Isto

significa que um cartucho pode ser modificado para, a partir das novas marcações,

gerar os códigos compatíveis com alguma plataforma específica (por exemplo).

O modelador, para obter a transformação desejada, tem como tarefa desenvolver o

modelo, incluindo as marcações corretamente. Esta, então, torna-se a primeira fase da

transformação. Depois disso, o modelador deve executar o processo de transformação

MDA que vai ler as especificações do projeto, identificar os cartuchos adequados e dar

a estes, os modelos correspondentes. Neste momento, todos os códigos pertinentes

são gerados.

IV.4. Personalização do Processo de Transformação

A abordagem MDA, por sua vez, está baseada em modelos, chamados de

metamodelos, que utilizam o padrão MOF (Meta Object Facility) para a definição

formal de construtores (por exemplo, entidades, relacionamentos, chave primária,

etc.). Estes construtores são usados nos modelos finais dos projetos a serem

desenvolvidos.

Para a criação de um cartucho ou a personalização de um cartucho existente,

deverá ocorrer a extensão do modelo original, incluindo as classes e métodos que

respondam às necessidades de transformação proposta. Por exemplo, supondo a

existência de uma interface ou classe abstrata denominada "Entity", poderia ser criada

uma classe concreta chamada "DWEntity", que tivesse o comportamento característico

desejado. Essa nova classe seria composta de métodos capazes de compreender as

novas marcas estabelecidas no modelo e realizar as transformações de modelo

apropriadas. Assim, quando surgissem novas situações no ambiente ou fosse

necessária a incorporação de um novo padrão de desenvolvimento à programação, o

modelador poderia decidir:

a) Incorporar um novo suporte de transformação de modelo, modificando o

cartucho previamente construído, tornando este novo comportamento permanente

para futuros projetos;

42

b) Ajustar o código gerado pelo cartucho sem a incorporação do novo padrão;

c) Utilizar a programação tradicional neste caso;

A primeira opção seria uma maneira de estender o cartucho para a geração de

código adaptado ao ambiente, trazendo produtividade para projetos futuros similares,

na percepção desta ocorrência.

No próximo tópico foram definidas, no formato de fluxo, as etapas lógicas seguidas

para a construção ou alteração de um cartucho qualquer. Cada atividade foi descrita

tomando-se como base o desenvolvimento realizado para a Poc (Proof of Concept).

Este esquema pode servir como guia para futuras extensões ao trabalho aqui iniciado.

43

IV.5. Fluxo Básico para Personalização de Cartuchos

Durante o desenvolvimento deste trabalho percebeu-se a necessidade de se

estabelecer um processo padrão que orientasse o desenvolvimento atual e futuro de

implementações em cartuchos existentes ou novos cartuchos. Neste tópico

estabelece-se uma descrição detalhada deste processo com todas as atividades

consideradas relevantes para a personalização de cartuchos no âmbito MDA. A

formalização das etapas descritas a seguir corresponde a uma nova contribuição

deste trabalho para a comunidade.

Nesta versão as etapas correspondem à seqüência de atividades realizadas

durante o desenvolvimento, isto é, o passo a passo seguido para a obtenção do

resultado alcançado. Estas etapas não foram previamente concebidas, aconteceram

de acordo com as necessidades do desenvolvimento. Acreditamos que em trabalhos

futuros, uma vez que já possuímos este passo a passo, teremos mais facilidade para o

desenvolvimento e poderemos aprimorá-lo e detalhá-lo ainda mais, auxiliando de

forma mais efetiva o desenvolvimento da comunidade que utiliza MDA.

Observou-se que as atividades necessárias à personalização de cartuchos estão

ligadas a três áreas distintas: Projeto, Desenvolvimento e Modelagem. A figura 8

abaixo apresenta um fluxo com macro-atividades características deste

desenvolvimento.

Figura 8: Fluxo com macro-atividades para personalização de cartuchos

44

Na etapa de projeto seriam estudadas todas as necessidades levantadas,

elencadas aquelas passíveis de desenvolvimento, determinado o melhor caminho de

desenvolvimento, estabelecido o resultado esperado e definido o passo a passo para

este desenvolvimento.

Figura 9: Sub-processo “Projetar novos requisitos para cartucho”

A figura 9 apresenta o Sub-Processo “Projetar novos requisitos para cartucho” com

o detalhamento de suas atividades, explicitadas a seguir:

− A1-Levantar Necessidades – esta atividade se refere a uma etapa mais

conceitual, onde seriam avaliados todos os novos comportamentos desejados para

o cartucho quanto à viabilidade de desenvolvimento, benefícios acarretados e

esforço de implementação. Em seguida seriam elencados aqueles

comportamentos com valor agregado mais significativo dentro das análises

efetuadas.

− A2-Estabelecer Requisitos – nesta atividade seriam detalhados os requisitos, já a

nível técnico, originados dos comportamentos desejados. Neste momento também

seriam discutidas as formas de desenvolvimento (p. ex: o que colocar para

resolução pelo Velocity, o que desenvolver em Java, etc.). Ao término desta etapa

o ambiente de desenvolvimento (macro) estaria estabelecido.

− A3-Desenvolver Modelo Exemplo para Teste – esta atividade foi considerada de

fundamental importância para o sucesso do projeto. A criação de um modelo

exemplo contendo a(s) situação(ões) levantada(s) concretiza os anseios

estabelecidos anteriormente e facilita o trabalho de desenvolvimento. É nesta

etapa que se determina o resultado prático esperado para cada comportamento

selecionado para desenvolvimento.

45

− A4-Criar Código Resultante na Plataforma – a partir do modelo exemplo

desenvolvido, cria-se o código a ser gerado pelo cartucho. Esta atividade é uma

complementação da anterior, objetivando a visualização concreta do que se deseja

obter como resultado do desenvolvimento do cartucho. Esta etapa também tem a

finalidade de potencializar a criação de templates de código que padronizem e

uniformizem o resultado da implementação.

− A5-É Possível Enriquecer o Modelo Caracterizando os Requisitos? – durante

as duas atividades anteriores já se pode perceber as vantagens e viabilidade de se

enriquecer o modelo com novas marcas que descrevam os novos comportamentos

a serem implementados. Nesta etapa, determina-se, então, se estas marcas

devem ou não ser desenvolvidas e sua aplicabilidade.

− A6-Definir Marcas de acordo com a Semântica – esta atividade também é

conceitual, tendo a finalidade de determinar a criação de marcas compatíveis com

a semântica e não apenas visando a parametrização das opções do cartucho. O

objetivo das marcas deve ser sempre o enriquecimento do modelo, de tal forma

que o modelador possa utilizá-lo para caracterizar mais detalhadamente o

ambiente que está representando. O cartucho deverá, conseqüentemente,

identificar estas marcas e gerar os comportamentos esperados.

− A7-O Código criado é Compatível com os Requisitos? – esta é uma atividade

típica de validação, tanto dos requisitos quanto do comportamento esperado. O

objetivo é verificar se o resultado previsto é compatível com os requisitos

estabelecidos, isto é, se não foram gerados códigos incoerentes com a previsão

inicial. Deve-se, neste momento, analisar o ajuste a ser realizado. No fluxo foi

considerado que o ajuste a ser feito no código é mais comum. No entanto, pode

acontecer em algumas situações, que os requisitos devam ser ajustados (seja por

inviabilidade técnica ou mudanças conceituais).

− A8-É possível generalizar a solução? – esta é a última atividade da área de

Projeto e trata, exatamente, da análise de viabilidade da personalização proposta,

isto é, a verificação da possibilidade de generalização da proposição para outros

modelos diferentes daquele inicialmente desenvolvido. Em caso negativo, o

trabalho deve ser reiniciado a partir dos requisitos, uma vez que sua definição

influencia todo o planejamento da solução.

46

Na figura 10, abaixo se encontra o segundo sub-processo do processo de

personalização de cartuchos, o qual se acha associado à área de Desenvolvimento.

Figura 10: Sub-processo “Desenvolver transformações de modelo que atendam aos requisitos”

As atividades deste sub-processo, basicamente, se referem a detalhamentos de

implementação e que serão mais bem entendidas durante o próximo capítulo deste

trabalho com a apresentação da prova de conceito (POC – proof of concept).

− A9 – Criar estereótipos e tagged values compatíveis – na atividade A6, as

marcas a serem criadas (estereótipos e tagged values) já foram estabelecidas. A

atividade atual refere-se à implementação da definição prévia. O criador do

cartucho, deve obter o modelo associado às marcas (profile no AndroMDA) alterá-

lo de acordo com sua necessidade, compilá-lo e disponibilizá-lo para uso pelo

cartucho que deseja modificar ou criar.

− A10-Existem Metafacades passíveis de Extensão? – nesta atividade o criador

de cartuchos deverá analisar se existem cartuchos existentes que podem ser

utilizados para a construção em andamento ou se é mais viável a criação de um

novo cartucho desde o início. Uma vez que a variedade de cartuchos é bastante

grande, considerou-se que o desenvolvimento de um cartucho completo é menos

freqüente e reuso de códigos anteriores é muito mais constante. Após esta

definição, o criador deve verificar se os metafacades previamente construídos

neste cartucho já possuem comportamentos que podem ser estendidos e

aproveitados na nova implementação.

− A11-Criar novo metafacade – nesta atividade (negação da atividade anterior), o

criador deverá criar um novo modelo de classes e criar um metafacade adequado

às suas necessidades a partir dos metafacades básicos da ferramenta MDA

47

utilizada. O AndroMDA já oferece um conjunto de metafacades com

comportamentos úteis ao desenvolvimento de código.

− A12-Estender Metafacade Existente – nesta atividade (aceitação da atividade

A10), o criador abrirá o modelo de classes do cartucho escolhido e adicionará sua

classe como uma especialização de uma classe pré existente que seja compatível

com suas necessidades.

− A13-Configurar Arquivos de Especificação de Cartucho – após a criação das

classes o criador deverá estabelecer as configurações necessárias nos arquivos

correspondentes da ferramenta MDA escolhida. Para o AndroMDA, os arquivos a

serem configurados são: Cartridge.XML (onde são especificados os suportes a

metafacades, os modelos (templates), as propriedades (property references), os

arquivos para uso do Velocity, etc.), Metafacades.xml (onde são especificados os

metafacades para o metamodelo correspondente), Namespace.xml (onde o

cartucho é registrado dentro de um descritor de namespaces) e Profile.xml (onde é

feito o mapeamento dos estereótipos e tagged values).

− A14 – Construir Transformações – esta atividade representa uma típica tarefa de

desenvolvimento de software. O criador desenvolverá os códigos em Velocity ou

Java capaz de gerar o que foi definido pela área de projeto e realizar os testes

correspondentes.

Após a construção e teste do cartucho, a etapa de homologação do projeto

desenvolvido consiste na criação de um projeto MDA, desenvolvimento de um modelo

utilizando a semântica pré estabelecida através das marcas e geração do código

desejado. Estas atividades estão contempladas na figura 11, abaixo.

Figura 11: Sub-processo “Modelar Exemplo e Executar Transformações”

− A15–Configurar Arquivos de Especificação do Projeto – esta atividade

corresponde à primeira etapa a ser realizada após a criação do projeto pelo

48

software MDA. No caso do AndroMDA, a criação do projeto se dá quando o

modelador executa o comando mvn correspondente à geração do projeto. Esta

criação corresponde a um processo interativo, onde o AndroMDA faz diversas

perguntas e, a partir das respostas define o diretório do projeto com os arquivos de

especificação (por exemplo: modelo) vazios. Um dos arquivos criados é o

AndroMDA.xml, que contém todos os parâmetros a serem preenchidos a fim de se

personalizar as características do projeto, sendo esta a atividade a ser

desenvolvida neste ponto.

− A16-Expressar Semântica no Modelo Exemplo – a atividade deste item

corresponde à criação de um modelo lógico que represente todas as situações

previstas no projeto e estabelecimento da semântica no modelo através da

utilização dos estereótipos e tagged values previamente criados.

− A17-Executar as Transformações do Modelo – esta é a última atividade de

construção do cartucho, pois trata da geração do código a partir do processo MDA.

Ao término da execução do processo, os códigos correspondentes à

implementação efetuada devem ser gerados de acordo com o esperado.

Na figura 12 (abaixo), revisitamos o processo como um todo. Duas atividades finais

podem ser observadas, as quais complementam todo o processo dando um

fechamento à tarefa proposta.

Figura 12: Processo de Personalização de cartuchos

49

− A18-Transformações bem Sucedidas? – esta atividade representa uma

validação de todo o processo de construção. O criador retorna agora ao projeto do

cartucho e confere cada um dos requisitos propostos contra os resultados obtidos.

Se houverem discrepâncias, o retorno às atividades de desenvolvimento se faz

necessária para realização das correções dos desvios percebidos.

− A19-Liberar Cartucho para Comunidade – esta atividade encerra todo o

processo, com a liberação do cartucho para uso por outros usuários.

Evidentemente, ajustes posteriores podem ocorrer, uma vez que melhorias sempre

serão úteis na incorporação de novos conceitos.

O fluxo apresentado neste capítulo representa logicamente as etapas realizadas

neste trabalho para seu desenvolvimento. O desenvolvimento real de uma ferramenta

ETL apesar de seguir as mesmas etapas teria uma escala muito maior, onde o

processo descrito anteriormente poderia ser repetido diversas vezes ciclicamente até a

obtenção do cartucho completo.

Para uma clareza maior das etapas deste tipo de desenvolvimento, a prova de

conceito, no próximo capítulo, segue os passos de uma personalização de cartucho,

exemplificando como os objetivos propostos foram desenvolvidos, como podem ser

estendidos e como novos comportamentos podem ser adicionados a um cartucho

existente.

50

Capítulo V

PROVA DE CONCEITO O objetivo da Poc (Proof of Concept) é mostrar, em escala reduzida, que o

desenvolvimento de uma ferramenta ETL através de MDA, realmente, poderia

assegurar que o esforço do projeto (ou inteligência) esteja centrado na definição dos

modelos. Já o desenvolvimento do código estaria sob a responsabilidade das

transformações de modelo MDA culminando na geração de código. Isso aproximaria o

desenvolvimento ETL ao uso de linguagens declarativas (por exemplo, SQL), onde se

especifica o que se deseja obter e não como obter.

V.1. Premissas

Para o desenvolvimento da Poc, algumas simplificações foram aplicadas a fim de

limitar o alcance e acelerar o resultado.

A primeira simplificação está associada com a criação do cartucho. Visando um

desenvolvimento mais rápido e a limitação do esforço despendido, foi escolhida a

modificação de um cartucho pré-existente em vez da criação de um novo. O cartucho

do Hibernate provou ser o mais adequado, já que contém muitas especificações

relacionadas com a utilização de dados. Desta forma, esta versão da aplicação é uma

extensão da básica, usada anteriormente (FERNANDES, NETO, FAGUNDES et al.

51

2010), com requisitos mais apurados e objetivos mais específicos, conforme

comentado no capítulo III.

A segunda simplificação diz respeito à fonte de dados. Foi estabelecido que, apesar

da possibilidade do ambiente origem ser composto de diferentes fontes de dados

(arquivos de texto, planilhas, bases de dados de diferentes fornecedores, etc.), grande

parte das vezes esses dados são obtidos a partir de bases do ambiente OLTP. Assim,

o banco de dados OLTP foi escolhida como única fonte origem de dados.

Outra questão analisada, visando à simplificação, foi a linguagem escolhida para

geração de código. A linguagem do código pode ter influência significativa no

desempenho do processo (que no ambiente ETL é bastante importante). Entre as

linguagens candidatas, aquelas nativas do banco de dados seriam capazes de utilizar

as características de desempenho do banco (tais como funções e procedimentos

nativos do próprio SQL, opções de compartilhamento de memória, características de

compilação, entre outros) e, portanto, foram consideradas as mais adequadas para o

código a ser gerado na Poc. Apesar da grande variedade de linguagens disponíveis

para geração de código, visando ainda a simplificação para a Poc, foi decidido usar

uma única linguagem - PL / SQL - ligada ao banco de dados utilizado no experimento

(Oracle). No Apêndice V encontra-se um exemplo do desempenho obtido com o uso

desta linguagem para a carga do modelo definido para a Poc.

Finalmente, como última orientação para a simplificação, foi decidido o

estabelecimento de um limite para as situações abrangidas pelas transformações da

experiência, isto é, neste momento a meta não é o desenvolvimento da ferramenta

ETL e sim de uma prova de conceito da viabilidade e benefícios deste

desenvolvimento no futuro. Espera-se, contudo, que o código produzido seja

suficientemente flexível e que a experiência demonstre a capacidade de expansão e a

possibilidade de modificação dos resultados gerados.

Como mencionado anteriormente, a ferramenta utilizada em todo o experimento foi

o AndroMDA que, além de possuir código aberto e extensível, permitindo modificações

e agregações (ANDROMDA, 2011), também é utilizada no projeto MDArte, no qual

este trabalho se enquadra. Para a realização dos próximos passos, a ferramenta já

deve estar instalada. Para tal, a instalação deve seguir as instruções fornecidas pelo

fabricante da ferramenta ou o passo a passo disponível no site do MDARTE (2011).

52

O passo a passo a seguir será identificado de acordo com o fluxo estabelecido no

item IV.5 do Capítulo IV. Este fluxo estabelece um conjunto de etapas e atividades

para a personalização de cartuchos. Algumas destas etapas, considerando-se a POC

já foram previamente realizadas, pois tratam-se de etapas conceituais do projeto, não

sendo consideradas no detalhamento da POC. A vinculação será feita através da

codificação utilizada no fluxo: A1 até A17. Neste passo a passo, em alguns itens,

ocorreram aglutinações de etapas do fluxo descrito previamente e em outros maiores

detalhamentos. Isto se deu em virtude do objetivo deste passo a passo ser esclarecer

o leitor sobre o projeto desenvolvido. Desta forma, houve necessidade de se mudar a

ordem de apresentação para que a explicação fosse exibida juntamente com o

resultado obtido causando, aparentemente, modificações no fluxo, o que, de fato, não

ocorreu.

V.2. Passo 1 (A9): Parâmetros, estereótipos, valores

etiquetados e outros.

O primeiro passo na construção da Poc foi a escolha das informações a serem

fornecidas pelo modelador. Essas informações proporcionam opções para geração de

código e estabelecem limites para todo o projeto. Foram utilizados três níveis de

parametrização: nível da entidade (valores etiquetados), nível de atributo (valores

etiquetados) e nível de aplicação (propriedades no arquivo de configuração).

O modelador vai contemplar os dois primeiros níveis, durante a construção do

modelo, uma vez que o enriquecimento semântico ocorrerá durante a modelagem. O

terceiro nível está associado ao projeto como um todo, por isso, o modelador deve

definir estas informações diretamente no arquivo de configuração do projeto.

Neste trabalho foram definidos alguns estereótipos e diversos valores etiquetados

cujo uso será comentado ao longo deste capítulo, de acordo com as transformações

desejadas. No Apêndice III se encontra, em detalhes, o conjunto completo dos

estereótipos criados juntamente com uma explicação sobre seu uso. Seguindo os

objetivos estabelecidos pelo trabalho e, ainda, de acordo com as especificações

técnicas estabelecidas por KIMBALL & ROSS (2002) os estereótipos e valores

etiquetados foram concebidos visando aproveitar a semântica do ambiente. Em função

disso, tais estereótipos e valores etiquetados correspondentes podem ser

considerados como mais uma contribuição deste trabalho.

53

Na figura 13, a seguir, alguns desses valores etiquetados foram exemplificados na

entidade Clientes. O estereótipo <<EntityDW>> foi associado à entidade e o

estereótipo <<AttrDW>> aos atributos. Cada um desses estereótipos possui um

conjunto de valores etiquetados (tagged values) associados, que precisa ser

preenchido para caracterizar corretamente a entidade ou atributo correspondente.

Ainda na mesma figura, pode-se observar ao nível de entidade, que os valores

etiquetados Type (tipo de entidade), AlgorithmType (tipo de algoritmo a ser usado na

carga da entidade) e ChangeType (tipo de mudança de controle para entidades do tipo

Dimensão) foram preenchidos.

Figura 13: Marcações na entidade Clientes

Todos estes estereótipos e valores etiquetados estão disponíveis, para o

modelador, durante a construção do modelo. Já o criador do cartucho utiliza os

arquivos de configuração do mesmo (p.ex: profiles) para esta especificação. Estes

arquivos podem ser personalizados para conter todos os parâmetros que sejam

necessários ao enriquecimento do modelo e, em alguns casos, também utilizados para

informar ao cartucho características que afetem o código gerado.

Na Figura 14 se encontram alguns estereótipos e correspondentes valores

etiquetados (tagged values) definidos para a Poc. Pode-se observar que a

nomenclatura dos estereótipos e valores etiquetados criados é compatível com o

primeiro objetivo definido para a Poc, isto é, nomenclatura orientada ao ambiente.

Como exemplo, destacamos o valor etiquetado AlgorithmType (a ser vinculado a uma

entidade), que foi criado para atender a um dos objetivos da Poc: flexibilidade na

escolha dos algoritmos de carga. Neste caso, o modelador poderá determinar qual o

algoritmo de carga mais adequado para cada entidade.

54

Figura 14: Estereótipos e valores etiquetados para os modelos DW e OLTP

Alguns desses valores etiquetados estão associados a listas de valores pré-

definidos. Na figura 15 encontramos uma destas listas. O valor etiquetado (tagged

value) AttributeType se acha associado a uma lista chamada AttributeDWType, que é

exibida abaixo. Mais uma vez observa-se que os valores apresentados na lista se

referem a opções para uso do modelador criadas através do emprego da

nomenclatura característica do ambiente DW.

Figura 15: Opções de valores para a tag AttributeType

O terceiro nível de parametrização (global) é aplicável ao projeto como um todo e,

portanto, não está disponível durante a modelagem. O modelador deve preencher os

55

valores desejados diretamente no arquivo de configuração do projeto, que no caso da

ferramenta AndroMDA se chama AndroMDA.xml. O criador do cartucho realiza a

personalização desses parâmetros diretamente no arquivo de configuração do próprio

cartucho. Como decidimos simplificar este experimento utilizando um cartucho já

existente, somente precisamos modificar o arquivo cartridge.xml do cartucho usado.

Os parâmetros escolhidos para Poc podem ser vistos na Figura 16. Os mais

relevantes, no contexto deste trabalho, são:

• loadType - que indica o tipo de carga, e pode ser preenchido com inicial ou

incremental;

• datastageType – que indica o tipo de layout da área intermediária (Data Stage),

podendo ser preenchido com DW similar ou semelhante à OLTP.

A vinculação de loadType e datastageType ao projeto foi motivada pelo objetivo

"flexibilidade no modelo de extração e carga". A combinação destes parâmetros

produzirá diferentes códigos para a operação de extração e carga de dados. Cabe

observar que para a Poc, o uso de uma área intermediária foi planejado e considerado

para todos os códigos ETL gerados, de acordo com KIMBALL & ROSS (2002).

Figura 16: Propriedades globais para o projeto DwEtl no arquivo cartridge.xml

Os valores para estas propriedades são preenchidos no arquivo andromda.xml e

são específicos para cada projeto. Na Figura 17 há um exemplo deste tipo de

especificação. Podem ser observadas as mesmas propriedades destacadas

anteriormente. Neste caso, no entanto, os valores para as propriedades

correspondentes estão preenchidos.

56

Figura 17: Valores para propriedades do projeto DwEtl no andromda.xml

V.3. Passo 2 (A10 e A12): Personalização do

Metamodelo

Como já mencionado anteriormente, a fim de acelerar o desenvolvimento, a POC

foi construída a partir de um cartucho pré-existente. O cartucho escolhido foi o do

Hibernate, pois é associado com a persistência do banco de dados. A modificação no

cartucho visa à obtenção de informações de dois tipos de modelos: de classe (para a

definição de entidades e seus relacionamentos) e de atividades (para a definição de

transformações nos dados origem).

No modelo de classes foi incluída a classe DWEtlEntity e DwEtlEntityAttribute

utilizando o mecanismo de herança, desta forma, todos os métodos e atributos

previamente definidos para as classes existentes no Hibernate podem ser diretamente

utilizados (ou modificados), diminuindo o esforço de desenvolvimento. No modelo de

atividades (inexistente para o Hibernate) foram criadas as classes DwEtlActivity

DwEtlEntityTransform. A herança, desta vez, foi originada das metaclasses básicas do

próprio MDA.

Na figura 18 se encontram trechos do metamodelo de classes do Hibernate com a

derivação das classes DWEtlEntityAttribute (esquerda) e do metamodelo de atividades

com a derivação das classes DwEtlActivity e DwEtlEntityTransform. O Hibernate não

usava um metamodelo de atividades, desta forma, este modelo foi criado empregando

as classes originais desenvolvidas pelo AndroMDA. Observe a diferença entre o

metamodelo de classes do Hibernate (esquerda) e o metamodelo de atividades

incluído (direita).

57

Figura 18: Trechos dos metamodelos de classes e de atividades do Hibernate

No modelo de classes (esquerda) pode-se perceber que um método e diversos

atributos haviam sido desenvolvidos para o cartucho do Hibernate (por exemplo:

HibernateEntityAttribute). As generalizações feitas para a nova classe (por exemplo:

DwEtlEntityAttribute) herdam as características da classe anterior, possibilitando o

aproveitamento tanto dos métodos quanto dos atributos, permitindo a especificação de

diferentes objetivos e encurtando o tempo de desenvolvimento.

A personalização de um cartucho pré-existente é um truque de desenvolvimento.

Pode-se usar parte de um desenvolvimento anterior e realizar modificações ou

acréscimos de acordo com as novas necessidades.

V.4. Passo 3 (A14): Validação

Uma das metas definidas para a Poc foi a validação da modelagem de

transferência, isto é, a verificação da viabilidade de transferência de dados entre a

base OLTP e a base DW. Para atingir esse objetivo, decidimos criar algumas

restrições a serem observadas durante a elaboração do modelo. Estas restrições não

são opcionais, ou seja, não estão vinculadas a qualquer parâmetro. Todos os projetos

ETL precisam ser validados.

Para a criação de regras de validação, levamos em consideração que,

normalmente, a equipe DW é diferente das equipes OLTP. Desta forma consideramos

que seria razoável assumir que as mudanças nos modelos ocorrem de forma isolada.

Por este motivo, optou-se por estabelecer marcas em ambos os modelos (OLTP e

DW). Desta forma, cada equipe é responsável pela manutenção e correção de seu

58

modelo de dados. Quando ocorre uma mudança, seja no ambiente DW ou no

ambiente OLTP, as rotinas de ETL são reconstruídas e revalidadas.

A definição das restrições seguiu a orientação de não interromper o processo de

geração, no entanto, eventualmente, isto não é possível. Algumas das situações

críticas estão listadas na figura 19.

Figura 19: Algumas mensagens de erro

Foram estabelecidos dois níveis de erro: W (aviso) e S (erro grave):

− Para o nível W (aviso), as mensagens são gravadas em um arquivo

(dwetlError.log), no entanto, o processo não fica comprometido. Neste caso, o

usuário deve analisar o arquivo e fazer as correções no modelo, se desejar.

− Para o nível S (grave), as situações de erro são gravadas no mesmo arquivo

anterior, porém, há o impedimento da geração de rotinas de extração e carga.

Neste caso, há a obrigatoridade da correção.

A relação completa de mensagens de erro e verificações realizadas está descrita

no Apêndice II. Neste local poderá ser observada que várias das críticas remetem ao

modelo dimensional, isto é, se referem à integridade do modelo de acordo com os

preceitos estabelecidos por KIMBALL & ROSS (2002). Neste sentido tais verificações

se acham em acordo com as metas previamente estabelecidas e podem ser

consideradas como mais uma contribuição deste trabalho.

A título de exemplificação de uma operação de validação, destacamos o erro

E03W. Esta restrição tem a finalidade de verificar a existência de relacionamento entre

as entidades origem (OLTP) que serão fonte de dados para as entidades destino

(DW). A mensagem correspondente a este tipo de situação é a seguinte: dwETL-

59

E03W: A entidade DW &entidade não pode ser carregada pois não há relacionamento

entre as entidades OLTP que a carregam.

Para a POC foi estabelecido que quando duas ou mais entidades enviam diferentes

atributos para uma mesma entidade de destino, estas entidades origem devem estar

direta ou indiretamente relacionadas. Para realizar essa validação, o cartucho foi

obrigado a identificar todos os relacionamentos existentes entre duas entidades

quaisquer; mesmo que este relacionamento fosse realizado de forma indireta, isto é,

através de uma terceira entidade (por exemplo: de A para B através de C: A-> C-> B).

Esta análise também se tornou útil na criação das rotinas de carga, uma vez que

quando existe um relacionamento entre duas entidades, o cartucho gera um SQL de

junção (Join) entre estas entidades para as operações de carga, como apresentado na

figura 20 abaixo.

Figura 20: Join entre duas tabelas OLTP

Se ocorrerem mudanças nos relacionamentos entre as tabelas, automaticamente, o

novo caminho é encontrado e o SQL é reescrito no programa gerado. No apêndice VI

foram ilustrados alguns exemplos relativos às conseqüências para o código gerado de

modificações no modelo de classes da Poc, isto é, o que é produzido caso uma tabela

seja excluída do modelo ou relacionamentos sejam modificados.

V.5. Passo 4 (A14): A Geração do Código

Quando o processo de geração MDA para um cartucho identifica uma nova

metafacade, ele, normalmente, cria três arquivos de classes: uma interface, uma

classe abstrata e uma classe concreta. Para melhor compreensão do significado de

um metafacade para um projeto MDA, no apêndice I encontra-se uma explicação mais

detalhada sobre este conceito.

Dos arquivos gerados pelo processo MDA, somente o terceiro arquivo é modificado

pelo desenvolvedor do cartucho (classe concreta) visando à implementação de novas

60

funcionalidades. Os outros arquivos podem ser gerados novamente, durante a

compilação do cartucho. Esta forma de desenvolvimento garante que novas

implementações (de versão, por exemplo) nas metafacades do próprio MDA, sejam

atualizadas sem impacto.

No caso do experimento da Poc, foi dada seqüência à mesma filosofia, isto é, foram

criadas algumas classes especializadas, sem modificação das classes originais do

AndroMDA e sem modificação das classes do Hibernate. Por exemplo, para a

metafacade DwEtlEntityAttribute foram gerados os seguintes arquivos:

1. DwEtlEntityAttribute interface, que estende a metaclasse HibernateEntityAttribute

do Hibernate,

2. DwEtlEntityAttributeLogic classe abstrata, que estende uma classe e implementa

uma interface: HibernateEntityAttributeLogicImpl (class) e DwEtlEntityAttribute

(interface);

3. DwEtlEntityAttributeLogicImpl classe que estende a DwEtlEntityAttributeLogic.

No processo de compilação do cartucho, as classes associadas a cada elemento

do modelo são instanciadas e executadas de acordo com as especificações

estabelecidas no arquivo Cartridge.xml (para o AndroMDA).

Figura 21: Carga inicial da tabela de Fato Empréstimos

Embora não seja um objetivo pré-determinado, a legibilidade do código gerado foi

considerada um item importante para o usuário do cartucho. Assim, alguns padrões

61

foram utilizados no código gerado, tais como: um comando por linha, comandos SQL

com cláusulas alinhadas, recuo, etc., como exemplificado na figura 21. Para atender a

este requisito e permitir o desenvolvimento de algoritmos específicos para cargas

sensíveis, optou-se por estabelecer padrões de desenvolvimento (modelos) dentro do

código incrementado nas classes. A idéia é que estes trechos padronizados possam

ser facilmente substituídos, melhorados, modificados ou clonados para a geração de

uma nova opção de desempenho, visando à reorganização do comando para uma

melhor legibilidade ou o desenvolvimento da mesma lógica para fontes de dados

diferentes.

Figura 22: Esquema modelo de código para um tipo de carga

Na figura 22 existe um esquema representando um desses modelos. Pode-se

observar que as partes fixas não são afetadas por substituições nas partes variáveis.

62

Figura 23: Trecho de código correspondente ao esquema modelo

Na figura 23 se encontra um trecho de código produzido a partir do esquema

representado na figura 22. Pode-se observar que não só as partes variáveis podem

ser substituídas, como também podem ser repetidas quando necessário. Se houver

interesse na criação de novo padrão de carga, um novo layout de código pode ser

estabelecido. As partes variáveis são modificadas de acordo com o modelo de classes

DW do projeto (desenvolvido pelo modelador).

V.6. Passo 5 (A14): Construção do Cartucho

A última etapa do desenvolvimento de um cartucho é sua compilação, incluindo

todas as novas classes e seus códigos. Nesta etapa, se a compilação for bem

sucedida, o software MDA (no caso da Poc, o AndroMDA) torna este cartucho,

devidamente personalizado, disponível para uso pelos projetos ETL através do

armazenamento do código compilado no repositório MDA. A título de exemplo, para

um completo entendimento da Poc, nas próximas etapas será apresentado o projeto

criado para realização dos testes.

V.7. Passo 6 (A15): Criação do Projeto Exemplo Em se tratando da ferramenta AndroMDA, a criação de um novo projeto se inicia

com a execução de um procedimento específico (ver o passo a passo no site do

fabricante). Este procedimento, para criar um projeto vazio que venha a utilizar os

cartuchos corretos, realiza uma série de questionamentos relativos às características

do projeto. Uma destas questões trata do framework de persistência a ser adotado. No

caso da Poc, deve-se escolher o Hibernate.

Após a execução deste procedimento, será criado um diretório contendo pastas

específicas para os arquivos de configuração, arquivos de modelos, fontes Java, etc.,

além do arquivo XML com a configuração definida para o projeto (AndroMDA.xml). Por

exemplo, como o nome do projeto para a Poc foi chamado de cETLt, alguns dos

diretórios gerados foram:

− C:\cETLt\mda\src\main\config – onde se encontra o arquivo andromda.xml

63

− C:\cETLt\mda\src\main\uml – onde se encontra o arquivo com os modelos UML.

− C:\cETLt\core\target\src\org\andromda\cETLt – onde se encontram fontes Java

para a camada de persistência.

− C:\cETLt\web\target\src\layout – onde encontram fontes arquivos .css e .gif para

as interfaces web.

OBS: A variedade de diretórios está relacionada ao tipo de projeto e aos cartuchos

escolhidos durante sua instalação.

V.8. Passo 7 (A15): Configuração ETL

Com o projeto criado (e vazio), pode-se iniciar sua configuração e modelagem. Não

há obrigatoriedade de se iniciar pela configuração, no entanto, para efeito de

entendimento consideramos esta ordem mais adequada. O arquivo de configurações

do projeto (Andromda.xml) deve ser ajustado de acordo com as necessidades do

projeto. Neste arquivo (como já comentamos anteriormente) se encontram todos os

parâmetros globais, que afetam o projeto como um todo.

Figura 24 – Valores etiquetados para geração de código

Na figura 24, acima, estão os principais valores etiquetados (tagged values) que

afetam a geração de código. Alguns deles afetam o projeto como um todo, são os

parâmetros globais (tipo de data stage, tipo de carga). Os demais são especificados

ao nível de entidade permitindo que entidades diferentes possuam características

diferentes e, portanto, parametrização independente. Os parâmetros vinculados a

cada entidade devem ser especificados diretamente no modelo.

64

No arquivo de configurações do projeto (AndroMDA.xml) devem ser fornecidos

valores para os parâmetros globais (por exemplo: o layout da área intermediária:

classic - layout similar ao DW - ou fast - layout similar ao OLTP -, esquematizado na

figura 25, abaixo) além de diversos outros parâmetros gerais, de menor importância,

tais como: freqüência de commit, nome da origem de dados, prefixo para os arquivos

do código gerado, dentre outros.

Figura 25 – Esquema do Processo ETL

Ainda considerando o arquivo de configuração, outro parâmetro global digno de

menção é o tipo de carga: inicial ou incremental. Na carga inicial todos os dados são

carregados considerando-se que a base de destino está vazia. Na carga incremental,

a base de destino já está preenchida. Desta forma, de acordo com a estratégia

adotada individualmente por entidade, pode-se simplesmente atualizar os dados

existentes ou pode-se incluir uma nova versão daquela informação, como veremos

mais adiante.

V.9. Passo 8 (A16 e A17): Modelos OLTP e DW com

marcações

Conforme comentado no Passo 7, a etapa de criação do projeto gera diretórios

específicos para armazenamento dos arquivos do projeto. Seguindo esta orientação, o

arquivo contendo os modelos do projeto deve estar armazenado no diretório

..\mda\src\main\uml. Os modelos criados devem abranger todos os recursos

necessários à geração das aplicações responsáveis pelas tarefas de extração,

transformação e carga.

A modelagem deve utilizar as marcações definidas previamente (parâmetros

específicos para entidades e atributos) a fim de caracterizar o tipo de ação a ser

65

realizada para cada entidade. Para a Poc foram definidos dois modelos de classe: um

para o ambiente OLTP e outro para o ambiente de DW, apresentados na Figura 26.

Figura 26 – Dois modelos de classes

Na figura 27 foi destacada a classe cliente, pertencente ao ambiente OLTP. A

marcação no modelo correspondente ao ambiente OLTP é bastante simples: basta a

identificação da entidade alvo (EntityTarget) e do atributo alvo (AttrTarget), isto é da

entidade e do atributo correspondente no ambiente DW. Embora simples, essas

marcas fornecem a relação básica entre os ambientes (OLTP e DW). Na Figura 27, a

entidade Cliente (OLTP) é a fonte de dados para a entidade Clientes (DW), onde a

coluna Nome do Cliente (OLTP), virá a ser transferida para a coluna Nome de Clientes

(DW).

66

Figura 27 - Marcações no modelo OLTP

Na figura 28 se encontra em destaque a classe Clientes do ambiente DW. No

ambiente DW as especificações (marcações) são bem mais detalhadas do que no

ambiente OLTP, como pode ser visto pelas figuras acima. Foi levada em consideração

que a geração de ETL reúne questões técnicas (p. ex: característica da entidade: fato

ou dimensão) e ambientais DW (p. ex: tipo de algoritmo utilizado na carga de uma

determinada entidade). Assim, apenas a equipe de desenvolvedores DW poderia

definir estas características, com os conhecimentos necessários para o processo.

Figura 28 - Marcações no modelo DW

Ainda ao nível da entidade (apresentado na figura 26 – Empréstimos do modelo

DW) é possível determinar o melhor momento para realizar operações de agregação.

Esta opção somente é aplicável a Fatos. As opções criadas para a Poc são mostradas

na Figura 29. O valor "onExtraction" indica que a agregação deve ocorrer durante o

processo de extração, enquanto "onTransformation" indica que o processo de

agregação será concluído apenas após o término da carga. Esta opção é importante

porque afeta o desempenho da operação. As conseqüências (isto é, o código gerado

correspondente) de uso de cada uma destas opções estão detalhadas no apêndice III

(Profile de Persistência) relativo à utilização de agregação.

67

Figura 29 – Parâmetros para o processo de agregação

De acordo com KIMBALL & ROSS (2002), a carga incremental requer um

elaborado processo tanto para a especificação quanto para o desenvolvimento de

ambos os tipos de entidades: Fatos e dimensões. Enquanto os atributos da tabela de

dimensão são relativamente estáticos, os dados não são. Eles podem mudar, embora

lentamente, ao longo do tempo. Esta mudança requer uma estratégia para permitir

modificações sem invalidar as relações pré-existentes já registradas na base de

dados. Para atender a essa especificação, o modelador pode escolher entre

"Overwrite" (onde o novo valor substitui o valor antigo) e "AddRow" (onde uma nova

linha é incluída na tabela referente à mesma dimensão) para o parâmetro

ChangeType. Uma vez que esta estratégia pode ser diferente para cada entidade, este

parâmetro não é global.

Na Figura 30, é apresentada uma aplicação para carga incremental (parâmetro

global) para a entidade Cliente, onde foi escolhida a opção "Overwrite" para o

parâmetro "ChangeType". Neste trecho de código pode ser observado que se for

encontrado na base um cliente com o mesmo CPF daquele a ser incluso, os dados

são sobrepostos (UPDATE). Caso contrário, uma nova linha será acrescentada à

tabela (INSERT). Em ambos os casos, supõe-se que a chave primária é uma chave

substituta, obtida no momento da inclusão. No trecho em destaque as colunas Nome,

CPF e TipoCliente foram substituídos pelos novos valores recebidos da base original

(e transformados, opcionalmente).

OBS: Nesta aplicação também pode ser observada a execução da operação de

transformação juntamente com a operação de carga (representada pelo trecho

dwtransf_Clientes). Este assunto será explorado devidamente mais adiante neste

capítulo.

68

Figura 30 – Carga incremental da Dimensão Clientes com Overwrite

Na Figura 31 a dimensão Clientes foi gerada com a opção "AddRow". Pode-se

observar, no destaque, que, inicialmente, há uma atualização na linha existente, com o

preenchimento da data de vencimento. Isso garante que a relação com as linhas pré-

existentes (tabelas de fatos) é preservada. Em seguida está sendo incluída uma nova

linha onde a data final não é preenchida. Esta segunda linha estabelecerá

relacionamento com as novas linhas das tabelas de fatos que vierem a ser incluídas a

partir deste ponto.

69

Figura 31 – Carga incremental da Dimensão Clientes com AddRow

70

Para a abordagem AddRow, foi considerada a existência de três atributos no

destino: a data inicial, a data final e o indicador de versão de linha. Estes três atributos

são controlados pela aplicação de carga incremental, mas precisam ser identificados

no modelo de classe. O modelador poderá optar por utilizar apenas uma destes

mecanismos para controle da versão da linha: as datas de vencimento ou o indicador

de versão de linha. A opção "AddRow" sem a identificação de pelo menos um desses

atributos causa erro, impedindo a geração de código.

O desempenho da aplicação é uma preocupação significativa na geração

automática de código. Principalmente no processo de ETL, pois envolve grandes

volumes de dados. Para a Poc, a preocupação de atender a esse requisito guiou as

opções de projeto. Foi definida que a utilização de modelos de código facilita o

desenvolvimento e permitem que o construtor cartucho crie, rapidamente, uma nova

opção de desempenho que se adapte à situação específica (p. ex: tipo de banco de

dados ou padrões locais). A especificação do algoritmo é realizada ao nível de

entidade através da propriedade "AlgorithmType". Nesse experimento foram criadas

duas opções associadas a essa propriedade: CursorSequential e CommandDirect.

A Figura 32 é um trecho de código (a imagem foi cortada para facilitar a leitura),

onde a tabela Empréstimo (Fato) será carregada a partir da tabela correspondente no

OLTP, Empréstimo. Nesta opção, foi utilizado um cursor para a obtenção dos dados

na tabela origem. Ao ler cada linha da origem as seguintes etapas são realizadas:

− Geração de chave substituta;

− Obtenção das chaves das tabelas de dimensão;

− Transformação de dados (opcional);

− Inserção na tabela fato destino.

Nesta opção a operação de inserção é realizada linha a linha, tornando o

processamento mais lento, porém, pode ser interessante para utilização das

operações de transformação diretamente durante a leitura das linhas ou quando a

quantidade de linhas a ser carregada não for significativa.

OBS: No apêndice V (Desempenho na Carga) foi realizada a carga alguns dados e

mensurado seu tempo com os dois tipos de algoritmo apresentados na Poc.

71

Figura 32 - Fato com carga incremental na opção CursorSequential

72

A figura 33 (a imagem foi cortada para facilitar a leitura) realiza a mesma carga feita

anteriormente, mas com outro algoritmo. Neste caso, o desempenho foi deixado sob a

responsabilidade do próprio banco de dados, uma vez que a operação usa apenas

comandos SQL para executar a tarefa. Nesta opção, a etapa de transformação não é

feita neste momento. Este algoritmo pode ser utilizado em situações onde se deseja

liberar o ambiente OLTP rapidamente e processar dados em uma próxima etapa.

Figura 33 – Carga incremental do fato Emprestimos usando CommandDirect

V.10. Passo 9 (A16 e A17): A Transformação dos

Dados

Uma das características mais marcantes das ferramentas ETL é a possibilidade de

transformação dos dados, ou seja, a mudança entre o que está sendo lido da fonte de

dados e o que está sendo gravado no destino. A meta para esta característica foi a

opcionalidade, ou seja, o modelador pode estabelecer ou não transformações a serem

feitas entre as entidades OLTP e DW. Desta forma, a implementação desse recurso foi

realizada utilizando o modelo de atividades, de tal forma que um modelo de atividades

possa ser desenvolvido apenas para as entidades onde a transformação é necessária.

73

A OMG (Object Management Group) definiu especificações de um metamodelo

CWM (Common Warehouse metamodelo), que representa os metadados comuns de

um data warehouse (OMG, 2003). Neste metamodelo (CWM) há um sub-modelo

(Transformation Package) especificamente associado às operações de transformação

exigidas por um processo de ETL. Estes modelos foram usados como base para o

desenvolvimento do módulo de transformação.

Figura 34 – Atividades de Transformação

Como o módulo de transformação, nesta versão da ferramenta, foi considerado

opcional, o usuário do cartucho não é obrigado a utilizar o conjunto de atividades de

transformação disponibilizado, podendo até mesmo optar por não utilizar nenhuma

transformação. No exemplo da figura 34, foram escolhidas duas atividades

específicas: derivação de valor e conversão de valor. Cada uma destas atividades está

associada a colunas específicas da base origem ou da base intermediária, desta

forma, pode-se associar mais de uma transformação a um mesmo atributo e podem-se

criar diversas transformações de mesmo tipo para atributos diferentes.

O momento da transformação poderá variar de acordo com o atributo escolhido, o

tipo de transformação e o tipo de base intermediária (Datastage). Por exemplo,

quando a transformação é aplicável à coluna origem e possível de ser realizada

durante a fase de extração, a aplicação dará preferência por realizar a transformação

imediatamente neste momento. No entanto, se o tipo da base intermediária for

“FastOLTP”, a operação será adiada para execução posterior.

74

Foram previstas cinco operações de transformação nesta versão: conversão (um

valor é substituído por outro), constante (um valor específico associado a um atributo),

derivação (um atributo gerado a partir de uma operação envolvendo outros atributos),

filtragem (linhas determinadas excluídas do resultado) e cisão (um atributo dividido em

partes e associado a outros diferentes atributos).

Figura 35 – Atividades de Transformação – código

A figura 35 apresenta a função de transformação para as entidades clientes e

empréstimos. Seu acionamento pode ser feito durante o processo de carga ou,

posteriormente, enquanto dos dados estão na área intermediária.

V.11. Passo 10 (A18 e A19): Análise dos Resultados

A última etapa da prova de conceito trata, justamente, de uma comparação entre os

objetivos propostos e os resultados alcançados. Para cada um dos objetivos

estabelecidos no capítulo IV, verificaremos a forma utilizada na Poc para seu

atingimento.

75

A principal preocupação e o mais importante objetivo proposto é a utilização do

conhecimento do modelador de tal forma que seja possível o enriquecimento do

modelo através do uso da linguagem nativa do domínio. Este objetivo foi atingido na

Poc (detalhado no apêndice III) através da especificação de estereótipos e valores

etiquetados, juntamente com listas de valores, que fazem referência aos conceitos de

Data Warehouse, no lugar de referência a técnicas de SQL ou de alguma linguagem

de programação. O modelador deve fornecer informações como: tipo de atributo

(indica a característica do atributo no ambiente: uma medida, uma descrição, uma

surrogateKey, etc.), tipo de medida (indica o tipo de medida do negócio: aditiva, semi-

aditiva ou não aditiva), tipo de agregação (indicando o momento da operação de

agregação: na extração ou na transformação), tipo de mudança para dimensões

(indica o comportamento quando ocorrem mudanças na dimensão), granularidade da

entidade de tempo, tipo de entidade (dimensão ou fato). Não há referência direta a

joins, group by, union etc., tal como previsto no primeiro objetivo.

O segundo objetivo se referia à possível resistência por parte dos usuários em

relação à performance do código gerado. Segundo Muñoz, Mazón e Trujillo (2010)

mesmo a utilização de consolidadas ferramentas de mercado requerem grandes

requisitos de hardware para sua execução. Desta forma, na Poc, foi adotada uma

estratégia diferenciada, a criação de algoritmos compatíveis com as situações que se

apresentassem. Para tal, adotou-se a utilização de templates de código visando à

simplificação na criação de novos algoritmos. Inicialmente foram criadas duas opções

(CursorSequential e CommandDirect) com uso individual por entidade. Por

conseguinte, o modelador faria a opção por um algoritmo específico de acordo com a

entidade. Novos algoritmos poderiam ser criados paulatinamente à medida que

situações mais complexas ou mais distintas se apresentassem. A título de exemplo, no

apêndice V (Desempenho na Carga) foi feita a carga do modelo da POC com os dois

algoritmos inicialmente previstos e desenvolvidos. Os tempos obtidos podem ser

usados como base para avaliações em ambientes reais e construções de novos

algoritmos ainda melhores.

O próximo objetivo se refere à integridade na transferência de informações entre a

fonte de dados e o destino. Este objetivo está relacionado à mudança de layout de

qualquer dos modelos (origem ou destino). Para atingi-lo foram criadas diversas

criticas que verificam as regras do ambiente de acordo com KIMBALL & ROSS (2002).

Estas críticas (detalhadas no apêndice II) validam o modelo data warehouse e a

viabilidade de obtenção e carga dos dados. Estas validações são feitas ao nível de

76

modelagem, antes da execução do código. Isso permite a antecipação de possíveis

situações de erro durante a execução.

Para que a identificação dos relacionamentos disponíveis fosse atingida (quarto

objetivo proposto), foram desenvolvidos algoritmos que analisam os modelos (fonte e

destino) e extraem os relacionamentos desenhados entre cada uma das entidades,

verificando a navegação entre as mesmas. Posteriormente esta identificação é usada

na verificação de integridade entre os ambientes e na criação das operações de

junção (joins) e grupamentos (group by) durante a etapa de geração de código. Nesta

versão da Poc, a detecção de mais de um caminho de navegação entre duas

entidades apresenta-se como erro. No entanto, em versões posteriores, já está

prevista a utilização de um valor etiquetado associado ao relacionamento de tal forma

quer o próprio modelador possa indicar seu caminho preferencial. Um exemplo para

melhor entendimento da capacidade de análise e extração dos relacionamentos foi

realizada no apêndice VI (Exemplos de Modificações no Modelo de Objetos) onde três

mudanças foram implementada no modelo e o código resultante destas mudanças

apresentado.

O próximo objetivo trata da opcionalidade da transformação de dados. Observou-se

que nem sempre existe a necessidade de modificação dos dados originais para o

armazenamento na base de dados destino. Foram adotadas duas estratégias para

atingimento do objetivo. Primeiramente a criação de rotinas independentes do código

principal de carga. Isso permite que, de acordo com o momento escolhido para sua

execução (na extração ou na transformação), elas sejam acionadas de dentro da

aplicação principal de carga ou posteriormente, a qualquer momento. Em segundo

lugar, a modelagem opcional das atividades para uma determinada entidade. Caso o

modelador não tenha transformações a adotar para uma entidade, basta que a

modelagem das atividades para aquela entidade não seja desenvolvida. Isso não

impede que a aplicação de carga seja criada. Ela é criada independentemente de

haver ou não transformação e independentemente da transformação ser ou não

aplicada.

O penúltimo objetivo trata da flexibilidade no modelo de extração e carga, isto

significa que a aplicação poderia realizar a carga de dados para uma base

intermediária (de acordo com KIMBALL & ROSS, 2002) com características de layout

diferentes. Considerou-se que esta base poderia ter um layout similar à base origem,

visando uma operação rápida (property datastageType=FAST) de extração de dados

77

ou um layout similar à base destino (property datastageType=CLASSIC). Para atender

a este objetivo foi criado o parâmetro de projeto, nomeado “datastageType” a ser

fornecido pelo usuário na configuração do projeto (no arquivo Andromda.xml). Sendo

assim, também este objetivo foi atingido pela Poc.

O último objetivo listado trata da extensibilidade inerente à abordagem, o qual a

Poc, na verdade é um exemplo. Este objetivo diz respeito à possibilidade de

desenvolvimento de cartuchos para objetivos específicos. A arquitetura MDA não

apenas permite este tipo de abordagem, como é uma de suas características mais

interessantes, pois permite que um usuário adapte um cartucho existente às suas

necessidades específicas. Com este trabalho e, mais especificamente com a Poc,

utilizou-se, justamente, esta característica da abordagem para adicionar

funcionalidades específicas de ETL (extract-transform-load) a um cartucho pré-

existente orientado para persistência de dados (Hibernate). Outra alternativa também

oferecida pela abordagem é a construção de um cartucho independente, voltado

exclusivamente para um uso particular. Esta poderia ser uma proposta para trabalhos

futuros à medida que outros tipos de fontes de dados fossem sendo incluídos no

desenvolvimento. A independência permitiria que o modelador optasse por outras

formas de persistência de dados e, ainda, utilizasse o cartucho ETL.

Após as observações registradas neste tópico conclui-se que todos os objetivos

propostos neste trabalho foram alcançados e que a Poc representa a primeira etapa

na construção de uma ferramenta para ETL (Data Warehouse) através de MDA com

geração de código independente de qualquer ferramenta de mercado e com a

possibilidade de adaptação às necessidades de performance do usuário.

78

Capítulo VI

CONSIDERAÇÕES FINAIS Na seção anterior foi apresentada uma versão inicial e limitada de um cartucho de

MDA para a construção de aplicações que auxiliam o desenvolvimento das operações

de extração, transformação e carga em ambiente de DW. Este trabalho, no entanto,

não estaria completo sem que alguma análise se fizesse em relação a softwares de

mercado. Afinal, existem diversas ferramentas ETL (comentado no item IV.1) já

consolidadas que oferecem alternativas aos usuários.

VI.1 MDA ou Ferramentas ETL?

De acordo com MUÑOZ, MAZÓN e TRUJILLO (2009) a utilização de ferramentas

especializadas (muitas delas associadas aos próprios bancos de dados, como é o

caso do Oracle Warehouse Builder, SQL Server Integration Services da Microsoft ou

do InfoSphere DataStage dentre outros) apesar de bastante difundido possui alguns

importantes inconvenientes: (i) notação proprietária, (ii) configuração e estrutura dos

processos ETL muito complexas e (iii) exigência de grandes requerimentos de

hardware. Estas características tornam difícil a integração com ambientes

heterogêneos e a curva de aprendizado aumenta. Desta forma, existem diversas

organizações que preferem desenvolver seus próprios processos ETL através de

79

desenvolvimento manual de código específico. Eles colocam também que esta forma

de proceder também implica em alguns problemas em função do seu alto custo de

manutenção. Assim, o ideal seria a modelagem conceitual dos processos ETL, que

melhoraria o desenvolvimento uma vez que documentaria o processo, suportando as

tarefas de definição. O que faltava nesta abordagem eram processos de geração de

código para uma plataforma específica.

Além dessas colocações, que reforçam a abordagem deste trabalho, outro aspecto

considerado importante é preocupação de manter a consistência de projeto e sua

implementação. No caso da abordagem MDA esta preocupação desaparece uma vez

que o código está sempre aderente ao modelo (projeto), portanto, a documentação se

acha sempre atualizada. Também ponderamos que o uso ou não de ferramentas pode

estar associado a fatores ambientais do cliente, tais como a pré-existência de

determinada ferramenta, parcerias estabelecidas, ambiente com uso de MDA,

documentação ou não dos processos, etc.

Com estas situações em mente, para estabelecermos uma comparação inicial,

foram imaginados três cenários envolvendo a construção de um Data Warehouse:

1. Ambiente com MDA

Neste ambiente, o usuário, já utiliza alguma ferramenta MDA. Neste caso, a

inclusão de um cartucho ETL, somente traria vantagens, pois o esforço a mais

despendido pelo usuário seria pequeno. Na prática, o código gerado para a carga do

ambiente DW poderia ser considerado um “plus” da abordagem MDA previamente

praticada.

O modelador, neste caso, já se acha familiarizado no desenvolvimento de modelos

e em seu enriquecimento visando à documentação e a geração de código. O uso do

cartucho ETL seria mais proveitoso e, naturalmente, mais rápido que o uso de uma

ferramenta ETL de mercado, não requerendo conhecimentos adicionais, além, é claro

de manter a compatibilidade entre o projeto (representado pelo modelo) e sua

implementação, mantendo a documentação atualizada.

2. Ambiente sem MDA, porém com documentação de modelos

Neste ambiente, o usuário não utiliza MDA, no entanto, estabelece documentação

de modelos e processos. Portanto a utilização de uma ferramenta MDA poderia ser

80

vantajosa uma vez que a modelagem seria aproveitada para a geração de código, o

qual será gerado antes mesmo da criação do banco de dados, permitindo avaliações

de impacto, desempenho etc. Neste caso, o usuário poderá optar por comparar

resultados e avaliar vantagens de uma abordagem ou outra de acordo com suas

necessidades. O ambiente MDA com seu cartucho ETL traria a este usuário as

seguintes vantagens:

− Permitir foco no negócio, diminuindo a preocupação com o desenvolvimento;

− Uso de terminologia característica do DW;

− Aumento do nível de abstração realizando a modelagem ao nível de classe e

reduzindo a dependência do conhecimento específico do software de banco de

dados;

− Flexibilidade do modelo de extração e carga;

− Flexibilidade de algoritmos de carga para alcançar o desempenho desejado (ver

apêndice V);

− Validação de modelos de dados;

− Identificação de caminhos alternativos para acesso a dados (ver apêndice VI);

− Independência da plataforma;

− Extensibilidade;

− Aprendizado pequeno para entendimento dos estereótipos e valores etiquetados

para enriquecimento do modelo.

− Compatibilidade de documentação entre o código e o projeto.

3. Ambiente sem MDA e sem documentação de modelos

Neste caso, certamente, o esforço de uso de uma ferramenta MDA superaria o

esforço de utilização de uma ferramenta ETL de mercado, uma vez que tais

ferramentas freqüentemente realizam engenharia reversa da base de dados. O

usuário (após o aprendizado especializado) passaria a atuar diretamente na

ferramenta com a visão direta das tabelas do banco de dados.

Para utilização de uma ferramenta ETL baseada em MDA, o usuário,

primeiramente, teria necessidade de criar os modelos (parcialmente através de

engenharia reversa), posteriormente, enriquecer estes modelo com o uso de

estereótipos e valores etiquetados visando à caracterização dos ambientes (OLTP e

DW) e a partir daí gerar código para uso no banco de dados.

81

Neste caso o mais difícil seria a manutenção dos modelos após a geração dos

códigos desejados uma vez que envolveria uma mudança cultural no cliente. Já que o

foco da abordagem MDA é a utilização de modelos e abstração do ambiente físico de

dados e código, a implantação deste tipo de abordagem em ambientes que não tem o

hábito do manuseio de modelos requereria um esforço maior do que o uso de

ferramentas que trabalham diretamente no ambiente físico de dados.

VI.2. Conclusões

No tópico V.11 foram detalhados os objetivos propostos juntamente com a forma

utilizada na Poc para cumprimento de tais objetivos. A partir deste detalhamento,

entende-se que a Poc não apenas demonstrou a possibilidade de sucesso na criação

de uma ferramenta para a geração de código ETL como também a extensibilidade no

desenvolvimento, permitindo a inclusão de novas características sempre que se

fizerem necessárias ou vantajosas.

No tópico VI.1 foram feitas argumentações e análises sobre o uso de MDA e de

ferramentas ETL de mercado. A partir do contexto apresentado fica claro que a

utilização de uma ferramenta ETL baseada em MDA somente seria competitiva (em

relação à utilização de uma ferramenta ETL de mercado) em ambientes que trabalham

a partir de modelos. Nestes ambientes, comparando-se apenas o esforço de

preparação dos modelos versus o esforço de aprendizado e utilização de uma

ferramenta diretamente no ambiente físico de dados, a abordagem MDA pode ser

competitiva. O usuário avaliaria as vantagens de cada uma das abordagens

considerando fatores como custo, confiabilidade, adequabilidade, performance, dentre

outros aderentes às suas necessidades. Já em ambientes onde a utilização de

modelos não é uma constante, o uso de uma abordagem MDA teria riscos de

insucesso, pois iria de encontro à cultura vigente, além de requerer um esforço de

implementação superior ao de uma ferramenta ETL comum. Neste caso o usuário teria

como principal fator de análise as vantagens do uso de modelos e documentação

conceitual, antes mesmo de chegar à comparação entre MDA e ferramentas ETL.

Ao longo deste trabalho pudemos observar que a abordagem MDA tem foco em

modelos e abstração de código, o cartucho desenvolvido em consonância com esta

abordagem refina-a ainda mais com o aumento do nível de abstração do modelador,

82

focando sua especialização em business intelligence, facilitando o desenvolvimento de

código além de utilizar a extensibilidade fornecida pela própria MDA. Entendemos que

estas características (abstração e extensibilidade) são fundamentais para o aumento

da eficiência e rapidez na construção de ambientes Data Warehouse, uma vez que

fornecem a possibilidade do desenvolvimento de uma ferramenta ETL baseada em

MDA com características similares às linguagens declarativas, onde se determina o

objetivo a ser alcançado e não o caminho a ser trilhado, deixando esta

responsabilidade para a ferramenta.

A partir dos resultados alcançados neste trabalho comprovou-se a viabilidade dos

objetivos propostos e que a criação de uma ferramenta para o ambiente ETL baseada

em MDA pode trazer valor agregado e tornar o desenvolvimento de código mais

eficiente e altamente orientado a modelos. Em virtude das peculiaridades observadas

no processo ETL (processo padronizado, características ambientais definidas,

conceitos bem estabelecidos) acredita-se mesmo que este nível de automação fique

bem perto de 100%.

Além dos resultados alcançados durante o desenvolvimento deste trabalho,

também se pode registrar o desenvolvimento bem sucedidos das contribuições

adicionais previstas na Introdução, quais sejam:

1. O estabelecimento de um processo padrão orientando o desenvolvimento de

implementações em cartuchos novos ou pré-existentes, cujo detalhamento se

encontra no tópico IV.5 do Capítulo IV.

2. A definição de estereótipos e valores etiquetados aderentes às especificações

técnicas estabelecidas por KIMBALL & ROSS (2002), que pode ser encontrada no

Apêndice III.

3. A relação mensagens de erro associadas à validação visando à integridade do

modelo de acordo com os preceitos estabelecidos por KIMBALL & ROSS (2002),

que pode ser visualizada no Apêndice II.

O próximo tópico apresenta uma relação de melhorias a serem implementadas na

POC a fim de tornarem-na uma ferramenta real. Também são feitas algumas

sugestões para futuros trabalhos abrangendo a utilização da ferramenta em um

ambiente real.

83

VI.3. Trabalhos Futuros

A primeira etapa deste item trata de implementações a serem realizadas no código

da Poc visando à construção de uma ferramenta ETL. Observamos as seguintes áreas

a serem exploradas ou incrementadas no trabalho atual:

− Estabelecer uma forma do modelador indicar o relacionamento a ser escolhido

(entre tabelas) no caso de haver mais de um disponível.

− Concluir a implementação das transformações de dados propostas na Poc.

− Identificação da nomenclatura de atributos e entidades x colunas e tabelas.

− Concluir as operações de carga para a base FAST ou entre a base CLASSIC e

o Data Warehouse.

− Possibilitar a mesclagem (union) entre tabelas e não apenas junção.

− Concluir as críticas de modelo.

− Possibilitar a criação de agregações automáticas.

− Incluir novo algoritmo de carga com novos planos de performance.

− Testes mais profundos com modelos maiores.

− Estabelecer commits intermediários para a carga com algoritmo

CommandDirect.

Após estas etapas a ferramenta estaria apta para utilização em um ambiente real.

Poderiam ser feitas análises comparativas com ferramentas de mercado, avaliação de

desempenho dos algoritmos, uso de diferentes fontes de dados, etc. Em um projeto

real poderiam ser observadas características como a adequabilidade, praticidade,

velocidade de desenvolvimento. Isto facilitaria, certamente, o entendimento para novas

proposições que viessem a incrementar o produto.

Neste momento podem-se propor algumas sugestões para trabalhos futuros que

tornem a ferramenta mais competitiva e útil para os usuários MDA e DW:

− Criação de um cartucho exclusivo ETL, tornando a ferramenta independente do

Hibernate.

− Indicação da fonte de dados para obtenção de informações fora do database,

envolvendo manipulação de outros bancos de dados ou outros tipos de

arquivos.

84

− Geração de dados usando outra linguagem (para outro banco de dados, por

exemplo).

− Implementação de novos tipos de transformações.

85

REFERÊNCIAS BIBLIOGRÁFICAS ANDROMDA. What is AndroMDA. Disponível em:

http://galaxy.andromda.org/index.php?option=com_content&view=category&layout=blo

g&id=19&Itemid=42. Acesso em dezembro 2009.

ANDROMDA. AndroMDA Cartridges. Disponível em:

http://www.andromda.org/docs/andromda-cartridges/index.html. Acesso em abril 2011.

ANDROMDA. AndroMDA Profiles. Disponível em:

http://www.andromda.org/docs/profiles.html. Acesso em abril 2011.

ANDROMDA. AndroMDA UML Common Metafacades Profile. Disponível em:

http://www.andromda.org/docs/andromda-metafacades/index.html. Acesso em maio

2011.

ANDROMDA. AndroMDA Metafacades. Disponível em:

http://www.andromda.org/docs-3.3/andromda-metafacades/andromda-uml-

metafacades/andromda-metafacades-uml/profile.html. Acesso em maio 2011.

APACHE. Apache Velocity Engine. Disponível em:

http://velocity.apache.org/engine/index.html. Acesso em dezembro 2009.

BOOCH, G., RUMBAUGH, J. & JACOBSON, I., 1998, The Unified Modelling

Language User Guide. 1 ed. Boston ,Addison-Wesley Professional.

86

CONTI, F., 2010, História do Computador e da Internet. Disponível em:

http://www.cultura.ufpa.br/dicas/net1/int-h150.htm. Acesso em julho 2010.

Cui, Y & Widom J., 2001, “Lineage Tracing for General DataWarehouse

Transformations”. In: Proceedings of the 27th VLDB Conference. Roma, Italy, 2001.

CHOWDHARY, P., MIHAILA, G., LEI, H., 2006, "Model Driven Data Warehousing

for Business Performance Management". In: ICEBE'06 Proceedings of the IEEE

International Conference on e-Business Engineering, pp. 483-487. Shanghai, China,

2006.

ELMASRI, R. & Navathe, S.B., 2005, Sistema de Banco de Dados, 4 ed. São Paulo,

Pearson-Addison-Wesley.

ESSAIDI, M., OSMANI, A., 2009, "Data Warehouse Development Using MDA and

2TUP". In: Proceedings of the 18th International Conference on Software Engineering

and Data Engineering (SEDE'2009), pp. 138-143. Junho, 2009, Las Vegas, Nevada,

USA.

ESSAIDI, M., OSMANI, A., 2010, "A Unified Method for Developing Data

Warehouses". In Proceedings of the 3d. International Conference on Information

Systems and Economic Intelligence (SIIE'2010), Fevereiro, 2010 - Sousse, Tunisia.

ESSAIDI, M., OSMANI, A., 2010, "Model driven data warehouse using MDA and

2TUP". In: Journal of Computational Methods in Science and Engineering, Volume 10,

Supplement 1/2010, pp. 119-134. ISSN:1472-7978 (Print), 1875-8983 (Online). DOI

10.3233/JCM-2010-0273.

FARHAD, J., 2002, The UML Extension Mechanisms. Dept of Computer Science

University College London. Disponível em:

http://www.cs.ucl.ac.uk/staff/ucacwxe/lectures/3C05-02-03/aswe15-essay.pdf. Acesso

em dezembro 2009.

FARHAN, M.S., MARIE, M.E., EL-FANGARY, L.M., HELMY, Y.K., 2011. "An

Integrated Conceptual Model for Temporal Data Warehouse Security". In: Computer

and Information Science, Vol. 4, No 4 (2011). ISSN 1913-8989 (Print), ISSN 1913-8997

(Online). doi:10.5539/cis.v4n4p46.

FERNANDES, L. & WERNER, C.M.L., 2009, “Sobre o uso de Jogos Digitais para o

Ensino de Engenharia de Software”. In: XXIV Simpósio Brasileiro de Banco de Dados

e XXIII Simpósio Brasileiro de Engenharia de Software, pp. 17-24 Fortaleza, Brazil.

Outubro 2009.

87

FERNANDES, L. A., NETO, B. H., FAGUNDES, V., ZIMBRÃO, G., SOUZA, J. M.,

SALVADOR, R., 2010, “Model-driven Architecture Approach for Data Warehouse”. In:

The Sixth International Conference on Autonomic and Autonomous Systems. ICAS

2010, pp. 156-161. Cancun, México. Março 2010.

FILHO, C. F., 2007, História da Computação - O Caminho do Pensamento e da

Tecnologia - ISBN 978-85-7430-691-9. 1 ed. Porto Alegre, EDIPUCRS.

FLUSSER, V., 2002, Filosofia da Caixa Preta: Ensaios para uma Futura Filosofia da

Fotografia. 3 ed. Rio de Janeiro, Sinergia-Relume Dumará.

GARDNER, S. R., 1998, “Building the Data Warehouse”. ACM Communications, v.

41, n. 9, pp. 52-60.

GARTNER GROUP, 2010, Business Intelligence. Disponível em:

http://www.gartner.com/it/products/research/asset_129487_2395.jsp. Acesso em

Agosto 2010.

GARTNER GROUP, 2011, Magic Quadrant for Data Integration Tools. Disponível

em:

http://www.tmforum.org/community/groups/data_migration/blog/archive/2011/01/06/gart

ner-november-2011-magic-quadrant-points-to-further-consolidation-in-data-

integration.aspx. Acesso em Julho 2011.

GLORIO O., TRUJILLO J., 2008, "An MDA Approach for the Development of Spatial

Data Warehouses". In: DaWaK'08 Proceedings of the 10th international conference on

Data Warehousing and Knowledge Discovery, pp. 23-32. ISBN:978-3-540-85835-5

doi>10.1007/978-3-540-85836-2_3. Turin, Itália. Setembro 2008.

HEDMAN, F.A., 2009, "Empleo De Mda En La Generación De Procesos". Trabalho

Final do Instituto Superior Politécnico José Antonio Echeverría Facultad de Ingeniería

Informática. Havana, Cuba.

HYENSOOK, K., OUSSENA, S., ZHANG, Y., CLARK, T., 2010, "Automatic

generation of data merging program codes". In: 5th International Conference on

Software and data Technologies (ICSOFT 2010), pp. 179-186. Greece, Julho, 2010.

INMON, W. H., 1992, Building the Data Warehouse. 1 ed. New York, John Wiley &

Sons.

KIMBALL, R., & ROSS, M., 2002, The Data Warehouse Toolkit. 2 ed. New York,

Wiley Computer Publishing.

88

KOCH, C. , 2002, Why doesn’t you ROI add up?. CIO Magazine. Disponível em:

http://www.cio.com.au/article/26111/why_doesn_t_your_roi_add_up_/. Acesso em

dezembro 2009.

KONTIO, M. , 2005, Architectural Manifesto: MDA for the enterprise. Disponível em

https://www.ibm.com/developerworks/ wireless/library/wi-arch16/. Acesso em

Dezembro, 2009.

LASKOSKI, J., 2011, MDArte disponível no Portal do Software Público. Blog

Informação e Conteúdo sobre TI. Disponível em: http://www.jack.eti.br/www/?p=1563.

Acesso em julho de 2011.

LEWIS, G.A., WRAGE L., 2004, Approaches to Constructive Interoperability

(CMU/SEI-2004-TR-020 ESC-TR-2004-020). Pittsburgh, PA: Software Engineering

Institute, Carnegie Mellon University, [Online]. Disponível em: http://www.sei.cmu.edu/

publications/documents/04.reports/04tr020.html. Acesso em Setembro, 2008.

MAFFEO, B. , 1992, Engenharia de Software e Especificação de Sistemas, 1 ed.

Rio de Janeiro, Editora Campus-Elsevier.

MATHEW, A.D., MA, L., HARGREAVES, D.J., 2008, "A conceptual data modelling

methodology for asset management data warehousing". In: Proceedings World

Congress for Engineering Asset Management, pp. 1086-1095, Beijing, China, 2008.

MAZON, J.N., TRUJILLO, J., SERRANO, M., PIATTINI, M., 2005, "Applying MDA to

the development of data warehouses". In: DOLAP'05 Proceedings of the 8th ACM

international workshop on Data warehousing and OLAP, pp.57-66 ISBN:1-59593-162-7

doi>10.1145/1097002.1097012. Bremen, Alemanha. Outubro-Novembro 2005.

MAZÓN, J. N., TRUJILLO, J., 2008, "An MDA approach for the development of data

warehouses". Elsevier Science Publishers B. V. - ISSN:0167-9236 - Volume 45 Issue

1, April, 2008. doi>10.1016/j.dss.2006.12.003.

MDARTE. Portal do Software Público Brasileiro:Comunidade MDARTE. Disponível

em: http://www.softwarepublico.gov.br/ver-comunidade?community_id=9022831.

Acesso em Maio 2011.

MORAL, O.R., SIMITSIS, A., GAMAZO, A.A., 2010, "GEM Requirement driven

Generation of ETL and Multidimensional Conceptual Designs". Technical Report.

Universitat Politècnica de Catalunya. Departament d'Enginyeria de Serveis i Sistemes

d'Informació.

89

MORESI, E.A.D., 2000, "Delineando o Valor do Sistema de Informação de uma

Organização". Ciência da Informação, v.29, n. 1, pp 14-24, Brasília, jan-abr 2000.

MUÑOZ, L., MAZÓN, J.N., PARDILLO, J., TRUJILLO, J., 2008, "Modelling ETL

Processes of Data Warehouses with UML Activity Diagrams". In: OTM'08 Proceedings

of the OTM Confederated International Workshops and Posters on On the Move to

Meaningful Internet Systems, pp. 44-53. ISBN: 978-3-540-88874-1 doi>10.1007/978-3-

540-88875-8_21. Monterrey, México, Novembro 2008.

MUÑOZ, L., MAZÓN, J.N., TRUJILLO, J., 2009, "Automatic generation of ETL

processes from conceptual models". In: DOLAP'09 Proceeding of the ACM twelfth

international workshop on Data warehousing and OLAP, pp.33-40. ISBN: 978-1-60558-

801-8 doi>10.1145/1651291.1651298. Hong Kong, China. Novembro 2009.

OMG, OBJECT MANAGEMENT GROUP. , 2003, Common Warehouse Metamodel,

CWM Specification ,V. 1.1, Vol.1. Disponível em: http://www.omg.org/spec/CWM/1.1/.

Acesso em dezembro 2009.

OMG, OBJECT MANAGEMENT GROUP, 2003, MDA Guide , V. 1.0.1. Disponível

em: www.omg.org/mda/mda_files/MDA_Guide_Version1-0.pdf. Acesso em dezembro

de 2009.

OMG, OBJECT MANAGEMENT GROUP, 2008, Semantics of Business Vocabulary

and Business Rules (SBVR), v1.0. Disponível em:

http://www.omg.org/spec/SBVR/1.0/PDF/2008-01-02.pdf. Acesso em: julho de 2011.

OMG, OBJECT MANAGEMENT GROUP, 2011, Catalog Of UML Profile

Specifications. Disponível em:

http://www.omg.org/technology/documents/profile_catalog.htm. Acesso em maio 2011.

OMG, OBJECT MANAGEMENT GROUP, 2011, MetaObject Facility (MOF).

Disponível em http://www.omg.org/mof/. Acesso em maio 2011.

PARDILLO, J. , MAZÓN, J.N., TRUJILLO, J., 2010, "Designing OLAP schemata for

data warehouses from conceptual models with MDA". In: Computer and Information

Science, Volume: In Press, pp. 1-13. ISSN: 01679236. DOI: 10.1016/j.dss.2010.04.006

PRESSMAN, R., 2001, Engenharia de Software. 6 ed. Rio de Janeiro, McGrawHill.

QUEIROZ, M. A., 2010,. Desenvolvimento de Software Orientado a Negócios, uma

nova abordagem sobre o conceito de desenvolvimento de software. Disponível em:

softwell.com.br/wp-content/uploads/2009/04/artigo.doc. Acesso em julho 2010.

90

SAURABH, A.K., NAGPAL, B., 2011. "A SURVEY ON CURRENT SECURITY

STRATEGIES IN DATA WAREHOUSES". In: International Journal of Engineering

Science and Technology (IJEST), Vol. 3 No. 4, pp.3485-3488. ISSN:0975-5462. Abril

2011.

SIMITSIS, A., 2005, "Mapping Conceptual to Logical Models for ETL Processes". In:

DOLAP '05 Proceedings of the 8th ACM international workshop on Data warehousing

and OLAP, pp. 67-76 , ISBN:1-59593-162-7 doi>10.1145/1097002.1097014. Bremen,

Alemanha, Outubro. Novembro 2005.

SIMITSIS, A., VASSILIADIS, P., 2003, "A Methodology for the Conceptual Modeling

of ETL Processes". In: The 15th Conference on Advanced Information Systems

Engineering (CAiSE '03), Klagenfurt/Velden, Áustria. Junho 2003.

SIMITSIS, A., VASSILIADIS, P., 2008, "A method for the mapping of conceptual

designs to logical blueprints for ETL processes". In: Elsevier Science Publishers B. V. -

Decision Support Systems, Volume 45 Issue 1, Abril, 2008, pp.22-40. ISSN: 0167-9236

doi>10.1016/j.dss.2006.12.002.

SKOUTAS, D., SIMITSIS, A., 2006, "Designing ETL processes using semantic web

technologies". In: DOLAP'06 Proceedings of the 9th ACM international workshop on

Data warehousing and OLAP, pp.67-74. ISBN: 1-59593-530-4.

doi>10.1145/1183512.1183526. Arlington, VA, USA. Novembro 2006.

SOLER, E., TRUJILLO, J., FERNANDEZ-MEDINA, E., PIATTINI, M., 2007, "A

Framework for the Development of Secure Data Warehouses based on MDA and

QVT". In: The Second International Conference on Availability, Reliability and Security

(ARES'07), 2007, pp.294-300. Vienna, Austria, 2007.

SOUZA, M.A., 2008, Informática na Educação Especial Desafio e Possibilidade

Tecnológica. Universidade Tecnológica Federal do Paraná. Disponível em:

www.diaadiaeducacao.pr.gov.br/portals/pde/arquivos/418-4.pdf. Acesso em julho

2010.

SPARX SYSTEMS, 2011, UML Profiles. Disponível em:

http://www.sparxsystems.com/resources/developers/uml_profiles.html. Acesso em

maio 2011.

TARAPANOFF, K., 2001. Inteligência Organizacional e Competitiva. 1 ed. Brasília,

Universidade de Brasília.

91

TRINTA, F., 2010. Model Driven Architecture. Disponível em:

www.cin.ufpe.br/~cagf/sdgrad/aulas/MDA.pdf. Acesso em julho 2010.

TRUJILLO, J., LUJÁN-MORA, S., 2003, "A UML Based Approach for Modeling ETL

Processes in Data Warehouses". In: ER 2003, 22nd International Conference on

Conceptual Modeling, pp. 307-320. Chicago, IL, USA. Outubro, 2003.

VASSILIADIS, P., SIMITSIS, A., SKIADOPOULOS, S., 2002, "Conceptual modeling

for ETL processes". In: DOLAP'02 Proceedings of the 5th ACM international workshop

on Data Warehousing and OLAP, pp. 14-21. ISBN: 1-58113-590-4

doi>10.1145/583890.583893

VASSILIADIS, P., SIMITSIS, A., TERROVITIS, M., SKIADOPOULOS, S., 2005, "A

generic and customizable framework for the design of ETL scenarios". In: Information

Systems, v.30 n.7, p.492-525. Novembro 2005 [doi>10.1016/j.is.2004.11.002].

WILKINSON, K., SIMITSIS, A., CASTELLANOS, M., DAYAL, U., 2010, "Leveraging

Business Process Models for ETL Design". In: ER'10 Proceedings of the 29th

international conference on Conceptual modeling, pp.15-30. Vancouver, BC, Canada.

Novembro 2010.

ZEPEDA, L., CELMA, M., ZATARAIN, R., 2009, "A Mixed Approach for Data

Warehouse Conceptual Design with MDA". In: ICCSA 2008, Part II, LNCS 5073, pp.

1204–1218. Perugia, Itália 2008.

92

Apêndice I

METAFACADES De acordo com o ANDROMDA (2011), Metafacades são fachadas (facades) usadas

para fornecer acesso a modelos carregados por um repositório. Estes "metafacades"

agem como escudos (ou interfaces) para a implementação do meta-modelo implícito.

Metafacades são geradas pelo meta-cartucho AndroMDA e utilizam o padrão MOF

(OMG’s MetaObject Facility). A especificação MOF é a base do ambiente padrão da

OMG onde os modelos podem ser exportados a partir de um aplicativo, importados

para outro, transportados através de uma rede, armazenados em um repositório e

depois recuperados, processados em diferentes formatos (incluindo XMI e OMG XML),

transformados e utilizados para gerar o código do aplicativo (OMG, 2011)

Metafacades são APIs objeto-orientadas que permitem o acesso a modelos a partir

de templates. Usando metafacades, os templates se tornam muito mais simples e

diretos, porque a inteligência e responsabilidade para a transformação de código e

geração é centralizada em objetos Java, e não na linguagem de script do modelo

(ANDROMDA, 2011).

93

Figura 36: Exemplo de metamodelo – noções básicas

O repositório MOF instancia um objeto Java para cada elemento no modelo que é

carregado no AndroMDA. A classe daquele objeto faz parte do metamodelo UML. No

exemplo da figura 36, quando se modela o atributo de uma classe, uma instância da

metaclasse "atributo" é instanciada. O atributo "birth: Date" do elemento de modelo

“Person" será instanciado como:

1. Um objeto da classe "Attribute" onde o atributo "name" será definido como “birth”.

2. Um objeto da classe "UMLClass" onde o atributo "name" será definido como

"Person" e uma referência para o objeto Attribute que tenha o nome de "birth".

O modelo acima representa, exatamente, o detalhamento da explicação que o

ANDROMDA METAFACADES (2011) faz em sua documentação. Em função da

utilização de metamodelos, o AndroMDA permite a adequação dos cartuchos às

necessidades dos desenvolvedores, permitindo customizações sem perda da

integridade de seu próprio código.

No trabalho realizado para a Prova de Conceito desta dissertação, utilizou-se uma

segunda simplificação: a extensão das classes de um cartucho existente. Desta forma,

todos os métodos e atributos previamente criados no cartucho original puderam ser

utilizados, acrescidos ou modificados sem perda do comportamento original.

Permitindo que o foco do trabalho fosse somente a geração ETL.

94

Figura 37: Metafacade DwEtlEntityAttribute

A figura 37 acima apresenta a estruturação básica realizada. O metafacade básico

do AndroMDA chamado EntityAttribute (correspondente a cada atributo das entidades

de um modelo) é estendido pelo cartucho do Hibernate através do metafacade

HibernateEntityAttribute, com a adição de novos atributos e métodos. Este, por sua

vez é estendido durante a adaptação do cartucho do Hibernate através do metafacade

DwEtlEntityAttribute a fim de incluir o comportamento característico desejado

associado a ETL. Seguindo este comportamento, os seguintes metafacades foram

criados no modelo de classes do Hibernate:

− DwEtlEntity (derivado de HibernateEntity) – representa uma entidade do modelo de

classes persistentes.

− DwEtlEntityAttribute (derivado de HibernateEntityAttribute) – representa um atributo

de uma entidade do modelo de classes persistentes.

95

− DwEtlAssocEnd (derivado de HibernateAssociationEnd) – representa um dos lados

de um relacionamento entre classes persistentes.

Para a representação da transformação de dados entre uma estrutura OLTP e uma

DW foram utilizadas duas classes presentes no modelo de metaclasses do próprio

AndroMDA (ActivityGraphFacade e EventFacade).

Uma vez que o Hibernate não possuía uma modelo de classes adequado ao

projeto, um novo modelo foi incluído para permitir o comportamento desejado. Os

seguintes metafacades foram criados:

− DwEtlEntityTransform (derivado do metafacade original do AndroMDA chamado

ActivityGraphFacade) – representa a entidade DW que receberá o dado

transformado.

− DwEtlActivity (derivado do metafacade original do AndroMDA chamado

EventFacade) – representa a transformação em si. Para a Poc, foram previstos

cinco comportamentos de transformação de dados:

o ActionConstant – para a atribuição de valores fixos, constantes a um atributo.

Por exemplo, na carga a indicação de tipo do cliente será sempre PF

(pessoa física).

o ActionConversion – para a tradução dos valores originais em valores

substitutos, visando a padronização. Por exemplo, o valor “1” passa a ser

armazenado como “M” para a coluna Sexo, enquanto o valor “2” passa a ser

armazenado como “F”.

o ActionDerivation – visando possibilitar a geração de novos valores

calculados. Por exemplo: vendas = qtde vendida * preço_unitário.

o ActionFilter – permitindo a seleção de apenas determinadas linhas no

momento da carga, estabelecendo uma filtragem dos dados originais. Por

exemplo: somente transferir linhas com data de venda maior que 01 de

janeiro de 2010.

96

o ActionSplit – com a finalidade de quebra do valor de um atributo em diversos

atributos. Por exemplo, partindo-se uma lista separada por vírgulas, seria

possível separar os diversos valores em atributos específicos no destino.

Apesar de diversas outras possibilidades de transformação existirem na literatura

(CUI, Y & WIDOM J, 2001), o estudo desenvolvido para a Poc foi limitado a apenas

este pequeno conjunto uma vez que o objetivo era apenas a exemplificação e não a

realização do desenvolvimento de um produto completo.

97

Apêndice II

VERIFICAÇÕES E MENSAGENS DE

ERRO As mensagens de erro listadas neste tópico estão vinculadas não apenas a críticas

realizadas na programação, mas também a toda uma conceituação do ambiente Data

Warehouse estabelecido por KIMBALL & ROSS (2002). Desta forma, a apresentação

destas mensagens será acompanhada de uma pequena explicação sobre a

verificação realizada e o conceito embutido (quando for o caso).

dwETL-E01S: Modelo vazio ou estereótipos não aplicados.

Este é um erro “severo” que impede o prosseguimento da geração de código. Indica

que não foram encontrados os estereótipos necessários à transformação de modelo,

desta forma, nenhuma classe foi identificada para transformação.

dwETL-E02w: EntidadeDW &entidade não está sendo carregada por entidade

OLTP.

Este é um “aviso” e não, obrigatoriamente, se constitui um erro. Indica que foi

encontrada uma entidade no modelo DW, que não é a entidade de tempo e que não

está recebendo dados de uma fonte origem. Neste caso o processo de transformação

de modelo não contemplará esta entidade.

98

dwETL-E03w: EntidadeDW &entidade não pode ser carregada pois não existe

relacionamento entre as entidades OLTP que a carregam.

Este é um “aviso”, no entanto, de acordo com as premissas deste trabalho se

constitui em um erro que impede o prosseguimento das transformações de modelo

para esta entidade. Foi estabelecido que quando duas ou mais fontes de dados

transferem informações para a mesma entidade destino, obrigatoriamente, deveria

existir um relacionamento entre estas fontes, portanto, o fato deste relacionamento

não existir impede a geração de código.

dwETL-E04w: Atributo &entidade.&atributo não é carregado por nenhum atributo

OLTP.

Este é um “aviso” indicando que um determinado atributo de uma entidade DW não

está recebendo nenhuma informação da fonte de dados. Entende-se que se uma

entidade DW está qualificada para recepção de dados através do aplicativo gerado

pelo processo MDA de transformações de modelo, todos os seus atributos devem

estar recebendo alguma informação. O usuário deverá, neste caso, não apenas

verificar se a fonte de dados foi corretamente identificada como também se o tipo de

atributo (valor etiquetado @andromda.persistence.property.AttributeType) está

qualificado adequadamente.

dwETL-E05w: Existe mais de um relacionamento válido para a carga da Entidade

DW &entidade.

Para a POC, considerou-se que havendo mais de um relacionamento válido entre

as entidades componentes da fonte de dados, o processo, para esta entidade não

deveria prosseguir. Outras opções seriam a escolha aleatória do relacionamento ou a

identificação por parte do modelador. Estas opções foram consideradas para trabalhos

futuros.

dwETL-E06w: Não foi possível determinar o relacionamento entre todas as

entidades origem para a carga de &entidade.

Este erro é um subtipo do E03, indicando que nem todas as fontes de dados estão

relacionadas. Existem alguns relacionamentos, porém, não são suficientes para

obtenção de todos os dados especificados. Há ausência de algum relacionamento.

dwETL-E07w: Atributo &entidade.&atributo possui estereótipo AttrOLTP, porém não

implementa Tagged Values.

99

Este tipo de erro indica que algum atributo foi marcado com o estereótipo

adequado, porém, está incompleto uma vez que o detalhamento que tem a finalidade

de caracterizar o tipo de medida (no caso de uma entidade fato) e o tipo de atributo

não foi preenchido, impossibilitando a geração de código para esta entidade.

dwETL-E08S: Existe mais de uma entidade 'Time' neste modelo.

A entidade de tempo representa a dimensão tempo (o “quando” um fato ocorreu)

em um data warehouse, porém, somente uma entidade deste tipo deve existir e todos

os fatos devem possuir associação a esta dimensão. A existência de mais de uma

entidade deste tipo não tem sentido e se constitui em um erro severo que inviabiliza o

prosseguimento do processo de transformação de modelo.

dwETL-E09S: Entidade Tempo &entidade não possui granularidade definida.

Este também se constitui em um erro severo que impede o prosseguimento de todo

o processo de transformação. A dimensão tempo identifica o nível de agregação dos

dados da entidade fato, chamado de granularidade. Isto tem conseqüências nas

operações de carga. Portanto torna-se indispensável sua identificação.

dwETL-E10S: Não encontrada nenhuma entidade 'Time' no modelo DW.

A entidade de tempo é uma obrigatoriedade em um data warehouse já que os

dados armazenados nas entidades de fato são históricas. Desta forma, a inexistência

de uma entidade de tempo inviabiliza o prosseguimento das transformações de

modelo. Este é um erro severo que interrompe todo o processo.

dwETL-E11w: Entidade fato &entidade não tem ligação com entidade 'Time'.

Esta é uma obrigatoriedade de todas as entidades fato. Uma vez que um fato é

uma série temporal, deve estar associada a uma entidade de tempo. Este tipo de erro

impede o prosseguimento do processo apenas para esta entidade.

dwETL-E12w: Entidade &entidade não possui atributos ou relacionamentos.

Em um modelo dimensional as tabelas de fato estão obrigatoriamente associadas a

dimensões. O erro identificado neste item indica que foi encontrada uma entidade (fato

ou dimensão) que não se encontra vinculada a nenhuma outra entidade ou que esta

não contém nenhum atributo. Este erro é impeditivo do prosseguimento do processo

para esta entidade.

dwETL-E13S: Entidade dimensão &entidade não possui Surrogate Key definida.

100

KIMBALL (2002) encoraja fortemente o uso de Surrogate Keys (chaves substitutas)

para as entidades de dimensão no lugar as chaves originais utilizadas nas fontes de

dados. Esta utilização simplifica significativamente o modelo dimensional e foi adotado

como regra para este trabalho. Como as dimensões estão ligadas a diversos Fatos,

um erro deste porte inviabiliza a geração de código para diversas entidades. Desta

forma a interrupção ocorre para todo o modelo e não apenas para esta entidade.

dwETL-E14w: Atributo &entidade.&atributo possui identificação de tipo inválida.

Este erro indica que um atributo específico se encontra no modelo, no entanto, o

tipo identificado está incompatível com sua entidade correspondente. Por exemplo,

uma descrição em uma tabela de fato.

dwETL-E15S: Entidade dimensão &entidade não possui tipo de controle de

mudança definido.

Todas as dimensões devem estabelecer o comportamento a ser seguido na carga

incremental. Individualmente seria impossível a geração de código da entidade.

Adicionalmente, a dimensão afeta as tabelas de fato associadas. Considerou-se,

portanto, que este seria um erro importante e todo o processo é interrompido.

dwETL-E16w: Não encontrados os atributos necessários ao controle de mudança

definido para a entidade dimensão &entidade.

Este é um erro vinculado a um controle de mudança do tipo “AddRow”. Não foi

encontrado o atributo identificado como DimRowIndicator nem as datas de início e fim

de validade. Desta forma não é possível a geração de código para esta entidade.

dwETL-E17w: Atributo &entidade.&atributo não possui identificação de tipo.

Este é um erro associado à geração de código. Indica que foi encontrado um

atributo em uma entidade DW onde o valor etiquetado “AttributeType” não está

preenchido. Isso impede a identificação do que deve ser atribuído a este elemento no

momento da carga. O usuário deve verificar o preenchimento deste valor etiquetado

para que a geração de código possa prosseguir para esta entidade.

dwETL-E18w: Atributo &entidade.&atributo possui tipo Surrogate Key, mas não

possui estereótipo 'Identifier'.

Esta é uma necessidade associada ao cartucho do Hibernate. Caso o atributo do

tipo SK não seja identificado como Identifier, qualquer tipo de relacionamento fica

comprometido e a leitura do modelo incorreta. Desta forma, para a geração de código

101

de uma determinada entidade, todas as colunas que participam da Primary Key devem

ser identificadas com este estereótipo.

dwETL-E19w: Atributo &entidade.&atributo está sendo carregado por atributo OLTP

incorretamente.

Esta mensagem está associada a diversas situações de atribuição inválida. Por

exemplo: transferência de dados para uma coluna identificada como Surrogate Key,

para uma coluna de tipo DimRowIndicator ou para uma de tipo Derived, dentre outros.

Os erros deste tipo ferem as regras do modelo dimensional e devem ser verificadas

pelo usuário. A mensagem identifica o elemento incorreto para a correção necessária.

O código para esta entidade não é gerado.

dwETL-E20w: EntidadeDW &entidade não possui tipo definido.

Este é um erro associado à modelagem dimensional. Significa que a entidade

mencionada na mensagem de erro não está associada aos tipos Fato ou Dimensão.

Em um modelo dimensional existem entidades do tipo Agregação, no entanto, estas

entidades não recebem dados de uma base origem. O erro acima indica que uma

entidade caracterizada com o estereótipo EntityDW, portanto, passível de recebimento

de dados de uma fonte de dados, não está identificada como Fato ou Dimensão

(correspondente ao valor etiquetado Type). Isto impede que as transformações de

modelo sejam aplicadas a ela, sendo, então o processo interrompido.

dwETL-E21w: Entidade fato &entidade não está relacionada a dimensões.

Este é um erro associado à modelagem dimensional. Indica que existe uma

entidade caracterizada como “Fato” que não tem relacionamento com nenhuma das

entidades caracterizadas como “Dimensão”. Este erro fere conceitualmente às regras

da modelagem dimensional. Desta forma ocorre a interrupção do processo de

transformação de modelo para esta entidade.

dwETL-E22w: Entidade dimensão &entidade não possui relacionamentos.

Este é um erro associado à modelagem dimensional. Indica que foi encontrada uma

entidade caracterizada como “Dimensão” que não se acha associada a nenhuma das

entidades caracterizadas como “Fato”. Isto significa que existe uma dimensão sem

finalidade no modelo. Em um modelo dimensional as dimensões têm a finalidade de

decodificar (ou esclarecer) as chaves dos fatos. Uma dimensão isolada não tem

finalidade para o modelo, portanto, o processo de transformação de modelo não gera

código para esta entidade.

102

dwETL-E23w: Agregação inválida para medida não aditiva na Entidade &entidade

Em um modelo dimensional, as medidas presentes em um Fato podem ser

classificadas como “aditivas”, “semi-aditivas” ou “não aditivas”. Nesta versão da

aplicação somente são aceitas medidas aditivas, pois permitem a execução da etapa

de agregação de dados de forma simplificada. Desta forma, o processo de

transformação de modelo é interrompido para esta entidade. Em trabalhos futuros uma

solução para os outros tipos de medida será considerado.

O conjunto de erros/validações a seguir está relacionado à etapa de transformação

de dados do processo ETL (extract-transform-load). As operações de transformação

são importantes para o processo ETL uma vez que visam a padronização dos dados

oriundos das diversas bases origem de forma a unificar as informações objetivando a

qualidade de dados na base Data Warehouse. Os erros deste tipo não causam a

interrupção do processo de transformação de modelo, são considerados “avisos”,

interrompendo apenas a geração do código de transformação.

dwETL-E24w: A ação &Action deve possuir exatamente um fluxo de entrada e um

fluxo de saída.

Este erro tem a finalidade de garantir que o fluxo do modelo de transformação

esteja completo e seja possível a identificação de seu início e fim. É exigida a

presença de uma e somente uma ação de entrada e uma e somente uma ação de

saída. Quando esta situação não é encontrada, o erro é apresentado e a geração de

código para a transformação é perdida.

dwETL-E25w: A ação &Action possui um fluxo de entrada sem o estereótipo

TransitionState.

Este é um erro de modelagem associado à leitura correta do modelo. Há

necessidade que tanto o fluxo de entrada quanto o de saída estejam associados ao

estereótipo TransitionState para que a leitura do modelo de transformações seja feita

corretamente. A ausência deste estereótipo interrompe a geração de código de

transformação.

dwETL-E26w: Encontrada ação sem nome. Verifique a transformação: &Transform.

Este é um erro simples, mas que impede a geração de código de transformação. A

motivação é muito mais conceitual que técnica. A nomenclatura utilizada no modelo

não é levada para o código, no entanto, todas as validações subseqüentes fazem

103

referência ao nome do elemento. Desta forma, sua ausência dificulta a identificação do

elemento incorreto em caso de erro.

dwETL-E27w: A ação &Action possui um fluxo de saída sem o estereótipo

TransitionState.

Este é um erro de modelagem associado à leitura correta do modelo. Há

necessidade que tanto o fluxo de entrada quanto o de saída estejam associados ao

estereótipo TransitionState para que a leitura do modelo de transformações seja feita

corretamente. A ausência deste estereótipo interrompe a geração de código de

transformação.

dwETL-E28w: Mais de uma seqüência de atividades encontrada para a mesma

entidade (mais de um início/fim). Verifique a transformação: &Transform.

Este erro tem a finalidade de garantir que o fluxo do modelo de transformação

esteja completo e seja possível a identificação de seu início e fim. É exigida a

presença de uma e somente uma ação de entrada e uma e somente uma ação de

saída. Quando é encontrada mais de uma ação de entrada ou saída, o processo de

geração de código para o fluxo é interrompido.

dwETL-E29w: Seqüência de atividades sem fim/início: &Action. Verifique a

transformação: &Transform.

Este é um erro de modelagem, indicando que no modelo de transformação

desenvolvido não foi encontrado o indicador de início, de fim ou ambos. Esta é uma

informação importante na medida em que as transformações de dados serão

executadas na ordem especificada pelo modelador e a ausência do indicador de

início/fim impede a identificação da ordem correta para execução das transformações.

Desta forma o processo de transformação de modelo MDA para geração de código da

transformação de dados é interrompido para esta entidade.

dwETL-E30w: A ação &Action não possui estereótipo válido para transformação.

Este erro indica que foi encontrada uma seqüência sem um dos estereótipos

previstos para transformação de dados. Isto significa que existe uma etapa de

transformação de dados não “entendida” pelo processo de transformação de modelo.

Desta forma, optou-se por interromper a geração de transformação para esta entidade.

dwETL-E31w: A ação &Action não possui indicação de nome da coluna constante.

104

Este erro está vinculado a uma ação de transformação do tipo “ActionConstant”,

onde uma coluna específica recebe um valor constante. Este erro indica que a coluna

não foi especificada. O modelador, neste caso, deve verificar o preenchimento do valor

etiquetado “ConsColumn”.

dwETL-E32w: A ação &Action não possui indicação de valor da coluna constante.

Este erro está vinculado a uma ação de transformação do tipo “ActionConstant”,

onde uma coluna específica recebe um valor constante. O erro indica que o valor

constante não foi preenchido. O modelador, neste caso, deve verificar o

preenchimento do valor etiquetado “ConsValue”.

dwETL-E33w: A ação &Action faz referência a um atributo inexistente para a

entidade correspondente.

Este erro pode estar associado a qualquer das transformações de dados propostas

por este trabalho. Indica que foi feita referência a um atributo não encontrado no

modelo de dados do trabalho. O modelador deve verificar o preenchimento do valor

etiquetado correspondente a nome de coluna na ação &Action mencionada no texto da

mensagem.

dwETL-E34w: A ação &Action não possui indicação de nome da coluna que sofrerá

a conversão.

Este erro está vinculado a uma ação de transformação do tipo “ActionConversion”,

onde uma coluna específica recebe um valor constante dependendo de um valor

informado “ConvOrigValue”. O erro indica que o nome da coluna cujo valor será

modificado não foi preenchido. O modelador, neste caso, deve verificar o

preenchimento do valor etiquetado “ConvColumn”.

dwETL-E35w: A ação &Action não possui indicação de valor original para a

conversão.



informado “ConvOrigValue”. O erro indica que o valor usado na comparação não foi

preenchido. O modelador, neste caso, deve verificar o preenchimento do valor

etiquetado “ConvOrigValue”.

dwETL-E36w: A ação &Action não possui indicação de valor resultante para a

conversão.

105



informado “ConvOrigValue”. O erro indica que o valor a ser usado para atribuição à

coluna após a comparação não foi informado. O modelador, neste caso, deve verificar

o preenchimento do valor etiquetado “ConvNewValue”.

dwETL-E37w: A ação &Action não possui indicação de nome da coluna derivada.

Este erro está vinculado a uma ação de transformação do tipo “ActionDerivation”,

onde uma fórmula é calculada para atribuição a uma coluna específica. O erro indica

que a coluna receptora do cálculo não foi informada. O modelador, neste caso, deve

verificar o preenchimento do valor etiquetado “DerivColumn”.

dwETL-E38w: A ação &Action não possui indicação de fórmula.

Este erro está vinculado a uma ação de transformação do tipo “ActionDerivation”,

onde uma fórmula é calculada para atribuição a uma coluna específica. O erro indica

que a fórmula não foi informada. O modelador, neste caso, deve verificar o

preenchimento do valor etiquetado “DerivFormula”.

106

Apêndice III

PROFILE DE PERSISTÊNCIA Um Profile UML tem a finalidade de fornecer um mecanismo de extensão genérica

para criação de modelos UML em domínios específicos. São baseados em

estereótipos e valores etiquetados (tagged values) que são aplicados aos atributos,

métodos e diversos outros elementos de um modelo UML. Um profile é um conjunto

de extensões de tal forma que, juntos, descrevem algum problema específico de

modelagem e facilitam a modelagem de construções nesse domínio (SPARX

SYSTEMS, 2011).

Para o OMG (2011), um Profile UML é uma especificação que faz um ou mais dos

seguintes itens:

− Identifica um subconjunto do metamodelo UML;

− Especifica "regras de boa formação" além daquelas já identificadas pelo

subconjunto do metamodelo UML.

− Especifica "elementos padrões" além daqueles já identificadas pelo subconjunto do

metamodelo UML.

− Especifica semântica, expressa em linguagem natural, além daquelas já

identificadas pelo subconjunto do metamodelo UML.

107

− Especifica os elementos do modelo comum, expressa em termos do profile.

Seguindo estas especificações, através do AndroMDA, é possível a criação (ou

modificação) de profiles para que os elementos contidos neste tipo de arquivo possam

ser aplicados nos modelos usados no processo de transformação MDA (ADROMDA,

2011).

Para este trabalho adicionamos alguns estereótipos e valores etiquetados (tagged

values) ao profile de persistência padrão utilizado pela ferramenta AndroMDA para

permitir que as marcações realizadas no modelo ficassem aderentes à nomenclatura

típica de um ambiente Data Warehouse (DW), conforme a figura 38.

Na seqüência deste tópico serão apresentados todos os estereótipos juntamente

com seus correspondentes valores etiquetados, cada um deles remetendo aos

conceitos de modelagem dimensional e conseqüências para o código gerado. Esta

contribuição do trabalho estabelece a primeira etapa para a construção de uma

ferramenta baseada em MDA que tenha como focos principais a abstração e a

utilização dos conceitos de data warehouse.

Figura 38: Estereótipos aplicáveis aos modelos de classes

Os estereótipos criados para o modelo de classes são de duas categorias distintas:

associados a entidades (EntityOLTP e EntityDW) e associados a atributos (AttrOLTP e

AttrDW).

108

Os estereótipos associados a uma entidade caracterizam o modelo específico e as

correspondentes entidades passíveis de uso pelo processo de transformação MDA

gerador de código. Quando o estereótipo EntityDW é associado a uma determinada

classe indica que aquele classe representa uma entidade do ambiente Data

Warehouse subordinado às regras de modelagem dimensional estabelecidas por

KIMBALL & ROSS (2002). Para o estereótipo EntityOLTP o objetivo é similar,

indicando o ambiente OLTP. Estes estereótipos estão descritos a seguir:

− EntityDW – seu objetivo é a identificação da entidade no ambiente DW que

receberá as informações oriundas do ambiente OLTP. Ao nível de entidade,

valores etiquetados (tagged values) foram criados para a especificação do tipo da

entidade (Type), tipo de algoritmo de carga (AlgorithmType), momento da

agregação (AggregationType), granularidade da entidade de tempo

(TimeGranularity) e tipo de controle de mudança para dimensões (ChangeType),

detalhados mais adiante.

− EntityOLTP – seu objetivo é a identificação da entidade no ambiente OLTP e sua

correspondência com a entidade DW.

Os estereótipos associados a atributos visam à identificação deste atributo no

contexto ao qual se liga. Esta caracterização é muito mais importante para o ambiente

DW, como descrito abaixo:

− AttrDW – seu objetivo é caracterizar, para DW, o atributo específico. Possui os

seguintes valores etiquetados (tagged values): tipo de atributo (AttributeType), tipo

de medida para entidades Fato (MeasureType) e tipo de atributo para entidades

Tempo (TimeType).

− AttrOLTP – seu objetivo é identificar o tipo de atributo na entidade OLTP e

estabelecer a ligação com o atributo correspondente na entidade DW.

O detalhamento dos valores etiquetados correspondentes aos estereótipos acima

está descrita abaixo, de acordo com o estereótipo:

EntityOLTP

109

Este estereótipo possui apenas um valor etiquetado (EntityTarget). É um elemento

multivalorado que indica a que entidades do modelo DW os dados desta entidade

(OLTP) serão destinados.

EntityDW

Este estereótipo possui 5 (cinco) valores etiquetados com objetivos diversos, a

saber:

− Type – determina o tipo de entidade do ambiente DW: “Dimension”, “Fact” ou

“Time”. Um Fato é a principal tabela em um modelo dimensional, onde as

medidas numéricas representam o desempenho do negócio. Já uma dimensão

tem o objetivo de descrever os fatos e contém informações textuais sobre os

fatos a que se relacionam. A entidade de Tempo, sempre presente em um DW,

indica o nível de agregação temporal das medidas dos fatos, sendo obrigatória

em todo Data Warehouse. A identificação do tipo tem conseqüências tanto para

a etapa de verificação quanto para a etapa de geração de código. Desta forma

sua identificação correta é primordial para o processo de transformação de

modelo.

− TimeGranularity – característica específica de uma entidade de tempo. Indica

o nível mais baixo de agregação para os fatos. Os valores válidos são: Year,

HalfYear, Quarter, Month, Week, Day, Hour, Minute, Second, SecondFraction.

De acordo com o valor escolhido, as operações de agregação de dados

geradas no código utilizarão funções específicas da linguagem escolhida para a

identificação da informação. Na figura 39 se encontram dois trechos do trabalho

desenvolvido. Inicialmente verifica-se que a entidade Tempo possui

TimeGranularity igual a Week. Abaixo verifica-se um trecho do código gerado

para a carga inicial da entidade Empréstimos (um Fato) onde a coluna

data_emprestimo (presente originalmente do ambiente OLTP) é comparada aos

atributos da entidade Tempo até atingir o nível “Week” (previamente

especificado) a fim de identificar a chave de Tempo a ser incluída em

Empréstimos.

110

Figura 39: Valor Etiquetado TimeGranularity e código gerado correspondente

− AlgorithmType – este é um valor etiquetado que pode ser utilizado tanto para

entidades de dimensão quanto para entidades de fato. Indica o tipo de algoritmo

a ser usado no código a ser gerado. Esta informação tem impacto direto no

código gerado. Nesta versão apenas duas opções de algoritmo são válidas:

CommandDirect ou CursorSequential. Uma vez que esta característica pode ser

diferenciada para cada uma das entidades do modelo, o usuário poderá optar

por aquele algoritmo mais adequado de acordo com parâmetros como: tipo de

entidade, quantidade de dados e freqüência de carga, dentre outros. Na figura

40 encontram-se dois trechos de código: o primeiro foi gerado para a carga

inicial na entidade Clientes utilizando o algoritmo “CursorSequential” (observa-

se que um cursor foi criado com o comando Select necessário à captura dos

dados. Posteriormente este cursor foi usado para leitura linha a linha e

conseqüente inclusão na tabela destino). O segundo código foi gerado para a

carga inicial da entidade Empréstimos utilizando o algoritmo “CommandDirect”

(observa-se que, neste caso, não há declaração de cursor. O comando para

inclusão da linha na tabela destino está diretamente vinculado a um comando

Select para captura do dado. Toda a performance fica sob a responsabilidade

do banco de dados).

111

Figura 40: Trechos de código para CursorSequential e CommandDirect

− AggregationType – opção específica para Fatos. Indica o momento mais

adequado para a execução de uma operação de agregação. As opções válidas

são: onExtraction e onTransformation. Na figura 41 encontram-se dois trechos

de código para o valor etiquetado AggregationType. No primeiro trecho pode-se

encontrar o comando de atribuição que aciona a rotina de transformação para

Empréstimos “r1 := DATASTAGEDB.dwTransf.dwTransf_Emprestimos(r1);”.

Este tipo de comando não existe no segundo trecho de código (criado para a

entidade Clientes) uma vez que foi escolhida a transformação após a carga na

área de estágio como uma operação isolada. Sendo assim, a operação de

carga (inicial ou incremental) não aciona a execução da rotina criada.

112

Figura 41: Trechos de código para onExtraction e onTransformation

− ChangeType – exclusivo para dimensões. Indica o tipo de mudança controlado

para a dimensão correspondente. Uma dimensão, apesar de ter seu layout

estável pode sofrer mudanças ao longo do tempo. No entanto, como ela contém

a descrição dos fatos aos quais está associada, deve ser capaz de manter a

informação correta para os fatos já cadastrados no banco de dados. Por

exemplo, suponhamos que a dimensão “vendedor” possua um atributo “região”

indicativa da região onde o vendedor trabalha. Caso um vendedor mude de

região, deve haver uma forma de garantir que os fatos criados quando o

vendedor trabalhava na região “A” permaneçam associados a esta região,

enquanto que os novos fatos criados indiquem, corretamente, que o vendedor,

agora, trabalha na região “B”. Desta forma, qualquer operação realizada pelo

usuário sobre a base de dados, obterá os dados corretos para cada região.

Neste trabalho, foram ofertados para o modelador duas opções de tipo de

mudança: Overwrite e AddRow. A opção Overwrite, simplesmente substitui o

valor da informação existente na dimensão pela informação nova, desta forma

toda informação do fato passado passa a identificar a nova informação nova. A

opção AddRow cria uma nova linha e torna a linha anterior inoperante. Assim,

os fatos antigos continuam apontando para as linhas anteriores e os novos fatos

113

apontam para as novas linhas. A figura 42 a seguir apresenta dois trechos de

código de carga incremental para a entidade Clientes. No trecho da esquerda a

opção escolhida para controle de mudança foi Overwrite. Pode-se observar que

caso a linha da dimensão seja encontrada (trecho “if c2%found”), o valor das

colunas “Nome, CPF e tipoCliente” é substituído pelo valor novo. Já no trecho

da direita, onde a opção de controle de mudança foi “AddRow”, caso a linha da

dimensão seja encontrada (trecho “if c2%found”), a linha anterior é expirada e

uma nova linha é incluída com data de fim de validade vazia. Para a realização

deste tipo de mudança, o modelador deve incluir alguns atributos na dimensão

correspondente: uma data de início de validade e uma data de fim de validade

e/ou um indicador seqüencial de linha. Estes atributos devem ser caracterizados

adequadamente através do valor etiquetado AttributeType.

Figura 42: Trechos de código para Overwrite e AddRow

114

Nos exemplos apresentados até este momento, freqüentemente, o modelador foi

obrigado a informar valores padrões para os valores etiquetados. Durante o

desenvolvimento da Poc, optou-se por estabelecer listas de valores que auxiliassem e,

simultaneamente, garantissem a acurácia no preenchimento destas informações no

modelo. Na figura 43 são apresentadas algumas das listas de valores constantes para

os valores etiquetados aos quais estas se encontram vinculadas.

Figura 43: Listas de valores para tagged values

Quando o modelador seleciona o valor etiquetado na ferramenta de modelagem é

apresentada uma lista de valores (figura 44) de tal forma que ele somente possa

preencher um dos valores da lista.

115

Figura 44: Preenchimento do valor etiquetado AttributeType

Uma segunda forma de estabelecer listas de valores limitantes é a associação com

um estereótipo específico, como acontece com o item ConsColumn. A este item foi

associado o estereótipo AttrDW. Isto significa que o modelador poderá preencher este

valor somente com atributos que tenham o estereótipo correspondente, garantindo a

validação em relação ao tipo de informação. Na figura 45, quando é selecionado o

valor etiquetado ConsColumn, o modelador, pressionando o botão “+” poderá escolher

entre os elementos de modelo que possuam o estereótipo AttrDW. Esta opção

também garante uma escolha compatível com o tipo de elemento desejado.

Figura 45: Seleção de elemento para o valor etiquetado tipoCliente

AttrOLTP

Este estereótipo possui apenas 2 valores etiquetados AttributeType, que tem a

finalidade de indicar o tipo de atributo origem (pode ser preenchido com OLTP ou

Work). Nesta versão da aplicação a origem de dados única é OLTP, no entanto, em

trabalhos futuros pode-se inferir a criação de novas opções. O segundo valor

etiquetado deste estereótipo é o AttrTarget. Trata-se de um elemento multivalorado

vinculado a elementos que possuam o valor etiquetado AttrDW. Sua finalidade é

indicar o destino do conteúdo do atributo ao qual esteja associado.

AttrDW

116

Este estereótipo exige um detalhamento maior, pois produz diferenças no código

gerado. Os valores etiquetados associados são: AttributeType, MeasureType,

TimeType.

− AttributeType – indica o tipo do atributo da entidade DW (fato, dimensão ou

tempo). Os valores válidos são: DimExpirationDate, DimRowIndicator,

DimValidateDate (associados a dimensões com o objetivo de controle de

mudança quando o valor etiquetado “ChangeType” estive preenchido com

“AddRow”); FactKey (associado a fatos com o objetivo de identificar os atributos

chave da entidade); Measure (associado a fatos com o objetivo de identificar os

atributos que correspondem às medições, isto é, valores do negócio. Estes

atributos sofrerão agregação caso sejam aditivos); Description (associado a

dimensões, indicando uma coluna descritiva, decodificadora de um fato);

Derived (associada a fatos, indicando que os dados serão gerados através de

fórmulas ou cálculos, possivelmente com o uso de transformações);

DimOriginalKey (associada a dimensões, caracterizando a chave original da

dimensão. A chave principal de uma dimensão é uma surrogate key, capaz de

permitir a utilização do controle de mudança); SurrogateKey (normalmente

associada a dimensões, no entanto, também pode ser usada para fatos. Indica

uma chave alternativa gerada no momento da carga. Esta chave não possui

vínculos lógicos com a linha original, trata-se de um número seqüencial. Seu

uso simplifica o modelo dimensional e facilita o controle de mudanças, no caso

de dimensões); TimeKey (associada à entidade de tempo, com a finalidade de

identificar o atributo chave. Este atributo será utilizado para relacionamento com

todos os fatos); DegeneratedDimension (associada a dimensões. Indica os

atributos da dimensão quando esta não possui atributos descritivos. Tem a

finalidade de impedir críticas na etapa de geração de código); Other (associada

a fatos. Tem a finalidade de indicar um atributo a ser ignorado no processo).

− MeasureType – valor etiquetado exclusivo para atributos do tipo Measure

(medida do negócio). Os valores válidos são: Additive (indica que esta medida

poderá sofrer agregação. Por exemplo: qtd_vendida); SemiAdditive (indica que

esta medida não poderá sofrer agregação direta. Por exemplo: saldo,

qtd_itens_estoque); NonAdditive (indica que esta medida não poderá sofrer

nenhum tipo de agregação. Por exemplo: %ocupação, temperatura diária).

Nesta versão da aplicação somente medidas aditivas são consideradas válidas

para operações de agregação em fatos. Uma solução de contorno é o uso de

117

uma fórmula de cálculo substituindo a agregação. No entanto, o usuário deverá

mudar o tipo de dado para Derived. Esta solução de contorno foi utilizada para o

atributo “Saldo_Real” do fato Empréstimos (figura 46). Esta solução, no entanto,

foi dada pelo modelador e não pela aplicação.

Figura 46: Operação de transformação para Saldo_Real

− TimeType – valor etiquetado exclusivo para a entidade de tempo e tem a

finalidade de identificar cada um dos elementos característicos de tempo até o

nível especificado para a granularidade da entidade. Os valores válidos são os

mesmos utilizados para a granularidade da entidade, isto é, Year, HalfYear,

Quarter, Month, Week, Day, Hour, Minute, Second, SecondFraction. A figura 39

(apresentada anteriormente) mostra que quando um atributo de um fato (uma

data) é associado à chave da entidade de tipo Time, são extraídos deste

atributo os conteúdos necessários às comparações com os atributos da

entidade de tempo que identifiquem sua chave primária. Sendo assim, torna-se

necessária a identificação de cada uma das colunas desta entidade que sejam

responsáveis pela caracterização da referida chave.

Os próximos estereótipos estão associados à modelagem das atividades de

transformação de dados. Estes estereótipos caracterizam o tipo de transformação de

dados a ser aplicada à entidade do diagrama.

Cada diagrama está associado a uma única entidade DW. Este diagrama deve indicar

o início do fluxo, as operações em ordem seqüencial de execução e fim do fluxo. A

figura 47 representa, exatamente, este processo para a entidade Empréstimos. Neste

caso ocorrem duas operações de transformação seqüenciais: uma derivação (usa o

estereótipo ActionDerivation) e uma conversão de valor (usa o estereótipo

ActionConversion).

118

Figura 47: Processo de transformação para o fato Empréstimos

O grupo de estereótipos descritos a seguir, aplicável ao modelo de transformação

de dados poderá ser usado repetidamente para a mesma entidade. A restrição é que

em um modelo existam transformações de uma única entidade. A figura 48 apresenta

cada um dos estereótipos com seus respectivos valores etiquetados.

Figura 48: Estereótipos aplicáveis aos modelos de atividades

119

O objetivo desta etapa é permitir que o modelador identifique algumas modificações

a serem aplicadas aos dados antes destes serem armazenados na estrutura criada no

ambiente DW. De um modo geral as atividades de transformação estão associadas à

limpeza dos dados ou equivalência entre dados de fontes diferentes. Por exemplo: em

uma determinada fonte de dados, a identificação de homens e mulheres é feito através

das letras H e M, já em outra fonte de dados esta informação utiliza as letras F e M e

em uma terceira, os valores 1 e 2. Quando estes dados forem enviados para uma

mesma coluna no ambiente DW, há necessidade de se estabelecer um padrão. O

modelador, neste caso poderá utilizar o método de transformação que considerar mais

adequado.

Nesta versão da aplicação, os seguintes comportamentos para transformação de

dados foram previstos, de acordo com os estereótipos definidos:

− ActionConstant – este estereótipo tem o objetivo de identificar o atributo no

ambiente DW que receberá valor constante. Os valores etiquetados são:

identificação do atributo (ConsColumn) e valor a ser atribuído (ConsValue). Na

figura 49, a coluna tipoCliente receberá o valor constante “PF” em todas as suas

linhas. Não há variação, nem dependência de qualquer condição. O valor é fixo.

Figura 49: Atribuição fixa à coluna tipoCliente

− ActionConversion – identifica o atributo no ambiente DW (ConvColumn) e,

condicionalmente, o valor a ser atribuído (ConvNewValue) caso o valor original do

dado seja compatível com o valor original informado (ConvOrigValue). Na figura 50

observamos a diferença entre este exemplo e o anterior. Neste caso Saldo_Real

somente receberá null se seu valor for 0. Caso contrário, seu conteúdo não será

afetado pela operação. A conversão, portanto, é uma operação condicional, nem

sempre será realizada.

120

Figura 50: Atribuição condicional a Saldo_Real

− ActionDerivation – objetiva a geração de um valor (DerivColumn) no ambiente

DW a partir de uma composição de colunas (DerivFormula) do ambiente OLTP. A

derivação representa a criação de um valor a partir de outras colunas presentes na

mesma linha. A fórmula é aplicada à coluna definida pelo valor etiquetado

DerivColumn. A figura 51 apresenta uma exemplificação deste uso: Saldo_Real

recebe uma operação de subtração entre Valor_Total e Valor_Pago.

Figura 51: Atribuição de cálculo a Saldo_Real

− ActionFilter – estabelece uma condição para filtragem de dados (FilterCondition) a

ser aplicada ao ambiente OLTP. Este comportamento foi previsto, porém, não foi

desenvolvido para esta versão da aplicação. O objetivo é que seja possível

estabelecer uma restrição sobre as linhas a serem obtidas do ambiente OLTP.

Caso a condição fosse verdadeira a linha seria transferida para o ambiente DW,

caso contrário, não.

− ActionSplit – determina um (ou mais) caractere (SplitCaracter) em relação ao qual

a coluna OLTP (SplitOrigColumn) será subdividida e seu conteúdo associado às

colunas DW (SplitDestColumn1, SplitDestColumn2, SplitDestColumn3 e

SplitDestColumn4) que estiverem preenchidas. Este comportamento foi previsto,

porém, não foi desenvolvido para esta versão da aplicação. A intenção é de dividir

uma texto qualquer entre diversas colunas na tabela destino. Deve ser informado

um caracter a ser usado para a separação do dado.

− EntityTransform – este estereótipo é aplicável à maquina de estado e tem a

finalidade única de identificar a entidade destino que receberá a transformação

121

(EntityDWTarget). A figura 52 apresenta os elementos UML que devem receber

este estereótipo: TrfClientes e TrfEmprestimos. Pode-se observar que cada um

dos diagramas se encontra subordinado a este elemento. Diversos diagramas

podem ser criados com seqüências de transformação de dados que atendam às

necessidades do usuário. A restrição é que não participem do mesmo diagrama

entidades diferentes.

Figura 52: Diagramas para Transformação de Dados

Quando todos os estereótipos, listas e valores etiquetados são devidamente

adicionados ao profile de persistência (escolhido em função do tipo de cartucho), o

processo de compilação e publicação do AndroMDA, garante que o arquivo resultante

seja disponibilizado para os modeladores nas ferramentas UML em uso. Esta

característica pode ser visualizada na figura 53 onde é possível a visualização do

profile de persistência a partir da ferramenta UML Magic Draw. Nesta imagem podem-

se perceber a presença de várias listas de valores mencionadas ao longo deste

trabalho assim como de alguns estereótipos (ActionConstant, ActionConversion e

ActionDerivation).

122

Figura 53: Profile de Persistência

As características iniciais fornecidas pelo padrão MDA foram estendidas para

acomodar os padrões semânticos DW e tornar a modelagem compatível com o

negócio do usuário.

123

Apêndice IV

MODELOS UML DA POC Neste apêndice serão apresentados os quatro modelos utilizados na Poc para

realização dos testes do cartucho desenvolvido. Nos modelos de persistência, nem

todas as entidades foram criadas com o intuito de transferência entre ambientes.

Algumas tiveram a finalidade única de conter erros para verificação das restrições

estabelecidas.

O modelo de persistência para o ambiente OLTP é composto das seguintes

entidades:

− Agencia – entidade auxiliar. Não é enviada ao ambiente DW.

− ContaCorrente – entidade auxiliar. Não é enviada ao ambiente DW.

− Pessoa – entidade utilizada para obtenção do CPF a ser armazenado na

entidade Clientes do ambiente DW.

− Cliente – seus dados serão transferidos para o ambiente DW na entidade

correspondente Clientes.

− Empréstimo – seus dados serão transferidos para o ambiente DW na

entidade correspondente Empréstimos.

124

Figura 54: Estrutura básica do modelo de persistência do ambiente OLTP

Na figura 54, se encontra a estrutura básica do modelo de persistência do ambiente

OLTP. Durante o desenvolvimento do projeto esta estrutura foi alterada diversas vezes

para auxiliar na simulação das situações de erro previstas.

Figura 55: Estrutura básica do modelo de persistência do ambiente DW

Da mesma forma, para o ambiente DW, foi criado um modelo simples (figura 55)

que permitisse ajustes e modificações para que fosse possível a simulação de

situações variadas previstas no projeto. Para o modelo DW, a estrutura é composta

das seguintes entidades:

− Teste – entidade auxiliar.

125

− Tempo – entidade auxiliar. Sua existência é obrigatória em ambiente Data

Warehouse.

− Clientes – entidade do tipo Dimensão. Seus dados são oriundos das

entidades Cliente e Pessoa, do ambiente OLTP.

− Empréstimos – entidade do tipo Fato. Seus dados são oriundos da

entidade Empréstimo, do ambiente OLTP.

Para este modelo, diversas simulações foram desenvolvidas, principalmente em

virtude dos parâmetros que caracterizam o resultado do código gerado. Sendo assim,

o modelo exposto na figura acima corresponde a um dentre muitos dos

preenchimentos parametrizáveis tanto para as entidades quanto para os atributos.

Para a simulação das tarefas de transformação de dados passíveis de ocorrer

durante uma operação de carga, foram criados dois modelos: modelo de ações para a

entidade cliente (apresentado na figura 56) e modelo de ações para a entidade

empréstimos (apresentado na figura 58).

Figura 56: Modelo de ações aplicáveis à entidade Clientes (DW)

Para a entidade Cliente utilizou-se apenas a associação de um valor fixo. Esta

operação causaria a criação de uma função em um pacote de transformações,

exemplificado na figura 57. Esta função poderia ser acionada durante a operação de

carga ou posteriormente quando a informação já estivesse na área intermediária (Data

Stage).

126

Figura 57: Código correspondente à transformação da coluna tipoCliente.

Neste exemplo (Figura 57), a função receberia uma linha similar à linha da tabela

Clientes (DW), transformaria esta linha e retornaria esta linha transformada.

Figura 58: Modelo de ações aplicáveis à entidade Emprestimos (DW)

Neste exemplo (Figura 58) são desejadas duas operações seqüenciais sobre a

linha da tabela Empréstimos. Na primeira ocorre o preenchimento de Saldo_Real

através de uma fórmula seguido de uma avaliação do resultado. Caso o resultado da

derivação fosse zero, seria atribuído null a Saldo_Real.

Na Figura 59 se encontra o código gerado para a realização das duas operações.

Pode-se observar que as duas operações são compostas dentro da mesma função.

Em ordem seqüencial, como definido pelo diagrama. O objetivo é que o modelador

estabeleça todas as operações que deseja realizar em um mesmo diagrama (nesta

127

versão da aplicação). Neste caso, o código gerado corresponde a uma única função

com todas as operações seqüenciadas, como abaixo.

Figura 59: Código correspondente à transformação da coluna Saldo_Real

Nesta versão da aplicação o código gerado está vinculado a um único pacote

(objeto package do Oracle), como pode ser visto na figura 60 a seguir:

Figura 60: Package de Transformação

No entanto, considerando-se a possibilidade de grandes quantidades de

transformações ou entidades participantes, pode-se pensar na criação de pacotes por

entidade, contendo diversas rotinas, de acordo com a quantidade de colunas

transformadas ou de acordo com o tipo de transformação, desde que seja mantida a

seqüência estabelecida pelo modelador.

128

Apêndice V

DESEMPENHO NA CARGA Neste apêndice serão apresentados os modelos de dados, o banco de dados

correspondente (script de criação das tabelas, índices e restrições de integridade) e

amostragens dos dados gerados para a realização do teste de carga inicial da Poc.

O modelo relacional do ambiente OLTP é apresentado na figura 61, a seguir. Pode-

se observar que este modelo é bastante similar ao modelo de classes apresentado

anteriormente. Isto ocorre porque o trecho do modelo de classes apresentado tratava

apenas das classes de persistência (de interesse deste projeto). No entanto, em um

modelo de classes real estarão presentes tanto as classes de persistência quanto as

demais classes do sistema (por exemplo, classes de interface).

O conjunto de classes, em uma abordagem MDA, será utilizado por cada um dos

cartuchos a que se referem. No caso deste trabalho as classes de persistência serão

lidas e tratadas pelo cartucho do Hibernate, com duas finalidades distintas: construção

da camada de acesso ao banco de dados e construção dos aplicativos ETL.

129

Figura 61: Modelo de Dados OLTP

Para a realização da carga de dados entre ambientes, a base OLTP foi carregada

com dados randômicos de acordo com o script exemplo descrito a seguir (para a

tabela Pessoa).

Pessoa – Os dados foram gerados utilizando-se o package DBMS_RANDOM para

montagem de valores diversos. O script utilizado para esta carga é apresentado na

figura 62. Com ele foram criadas 699.997 linhas na tabela.

Figura 62: Script para carga de dados da tabela Pessoa

Na figura 63 encontra-se um exemplo dos dados gerados para preenchimento

desta tabela.

130

Figura 63: Amostragem de dados da tabela Pessoa

Cliente – esta tabela já foi gerada levando-se em consideração o conteúdo da

tabela Pessoa uma vez que existe um relacionamento entre elas. Na tabela Cliente

foram carregadas 577.113 linhas. O script criado também utilizou o package

DBMS_RANDOM para geração dos dados numéricos e listas de valores em

memória para a criação dos dados alfanuméricos. Na figura 64 encontra-se uma

amostragem dos dados gerados para esta tabela.

Figura 64: Amostragem de dados da tabela Cliente

Agencia – para esta tabela foram criadas apenas 40 linhas. Na figura 65 encontra-

se uma amostragem dos dados gerados para esta tabela.

Figura 65: Amostragem de dados da tabela Agencia

ContaCorrente – esta tabela estabelece relacionamento com agencia, cliente e

indiretamente com Pessoa. Nesta tabela foram criadas 361.824 linhas. A seguir

(figura 66) uma pequena amostragem de dados.

131

Figura 66: Amostragem de dados da tabela ContaCorrente

Emprestimo - a última tabela do modelo possui um relacionamento com a tabela

contacorrente e diversos valores numéricos (gerados randomicamente). Para esta

tabela foram geradas 1.500.000 linhas. Uma amostragem destes dados se encontra

na figura 67.

Figura 67: Amostragem de dados da tabela Emprestimo

O segundo modelo de dados (apresentado a seguir na figura 68) corresponde à

base intermediária (Data Staging) similar, em layout, ao ambiente Data Warehouse

criado para a Poc.

Figura 68: Modelo de Dados Data Warehouse

Antes do início da execução das rotinas de carga, a tabela Tempo foi carregada a

partir das datas existentes na tabela Empréstimo do ambiente OLTP. A carga desta

tabela pode obedecer a outras regras do ambiente cliente, no entanto, a tempo de

carga dos dados na base DW, ela já deve estar preenchida.

132

A fim de estabelecermos um controle de tempo sobre a carga de dados foi criada

uma tabela auxiliar chamada CARGALOG composta apenas de duas colunas: texto e

data. O script apresentado na figura 69 foi executado visando o registro do intervalo de

tempo total de cada execução nesta tabela.

Figura 69: Script para carga da base DW

Clientes – para a carga desta tabela utilizou-se o script seqüencial (destacado na

figura 71). Foram carregadas 577.113 linhas em um tempo de 1:37min. (um minuto

e trinta e sete segundos). Na figura 70 é apresentada uma amostragem do

resultado da carga nesta tabela. Pode-se observar que a coluna “TipoCliente” já se

encontra preenchida. Este preenchimento foi realizado pela etapa de transformação

de dados ocorrida concomitantemente com a carga inicial.

Figura 70: Amostragem de dados da tabela Clientes

Uma vez que a quantidade de dados não era grande e a tabela não possuía muitos

relacionamentos, optou-se por realizar a carga com cursor, o que permitiu a execução

simultânea das operações de transformação de dados. O script de carga (já

apresentado anteriormente) se encontra a seguir (figura 71).

133

Figura 71: Script de carga para Clientes

Empréstimos (v1) – a carga desta tabela ocorreu para duas versões da aplicação.

Inicialmente utilizou-se o script apresentado na figura 72. Com esta rotina foram

carregadas 1.500.000 linhas em um tempo de 4:12 min. (4 minutos e doze

segundos).

Figura 72: Script de carga para Emprestimo – algoritmo CommandDirect

134

Empréstimos (v2) – para observarmos a diferença de tempo de carga entre os

dois algoritmos desenvolvidos, a tabela foi totalmente esvaziadas e uma nova carga

ocorreu, porém, desta vez utilizou-se o script apresentado na figura 73. Com esta

rotina foram carregadas 1.500.000 linhas em um tempo de 07:47min. (7 minutos e

quarenta e sete segundos). Apesar do tempo bem superior ao utilizado na primeira

versão, ganhou-se com a execução simultânea das transformações de dados

previstas para esta tabela, como pode ser observado na figura 74.

Figura 73: Script de carga para Emprestimo – algoritmo CursorSequential

Na amostragem de dados a seguir (figura 74) a coluna SALDO_REAL já aparece

preenchida (correspondendo ao resultado de VALOR_TOTAL – VALOR_PAGO).

Como os valores gerados foram aleatórios, o saldo aparece negativo neste trecho da

amostragem.

135

Figura 74: Amostragem de dados da tabela Emprestimos

O resultado destes testes indica que o usuário nem sempre precisará optar pelo

algoritmo mais rápido. Isso dependerá de sua estratégia de carga. De acordo com o

tempo previsto para a carga poderá ser mais vantajosa a utilização da carga

seqüencial com a execução simultânea das operações de transformação.

Como último assunto deste apêndice apresentamos o script para criação dos

bancos de dados OLTP e Data Warehouse (área intermediária) e algumas

informações sobre o equipamento utilizado para os testes:

1. Script para criação do banco de dados OLTP:

CREATE TABLE AGENCIA ( NUMERO NUMBER CONSTRAINT SYS_C006483 NOT NULL , NOME VARCHAR2(100 BYTE) NULL , ENDERECO VARCHAR2(100 BYTE) NULL ); CREATE UNIQUE INDEX PK_AGENCIA ON AGENCIA (NUMERO ASC); ALTER TABLE AGENCIA ADD CONSTRAINT PK_AGENCIA PRIMARY KEY (NUMERO); CREATE TABLE CLIENTE ( ID NUMBER CONSTRAINT SYS_C006485 NOT NULL , ENDERECO VARCHAR2(100 BYTE) NULL , NOME VARCHAR2(100 BYTE) NULL , PK_PESSOA NUMBER NULL ); CREATE UNIQUE INDEX PK_CLIENTE ON CLIENTE (ID ASC); ALTER TABLE CLIENTE ADD CONSTRAINT PK_CLIENTE PRIMARY KEY (ID); CREATE UNIQUE INDEX IX_CLIENTE_01 ON CLIENTE (PK_PESSOA ASC); CREATE TABLE CONTACORRENTE ( ID NUMBER CONSTRAINT SYS_C006487 NOT NULL ,

136

NUMERO NUMBER NULL , AGENCIA_REF NUMBER NULL , CLIENTE_TITULAR NUMBER NULL , CLIENTE_CONJUNTA NUMBER NULL ); CREATE UNIQUE INDEX PK_CONTACORRENTE ON CONTACORRENTE (ID ASC); ALTER TABLE CONTACORRENTE ADD CONSTRAINT PK_CONTACORRENTE PRIMARY KEY (ID); CREATE INDEX FK_CONTACORRENTE_01 ON CONTACORRENTE (AGENCIA_REF ASC); CREATE INDEX FK_CONTACORRENTE_02 ON CONTACORRENTE (CLIENTE_TITULAR ASC); CREATE INDEX FK_CONTACORRENTE_03 ON CONTACORRENTE (CLIENTE_CONJUNTA ASC); CREATE TABLE EMPRESTIMO ( VALOR NUMBER NULL , TX_JUROS NUMBER NULL , TOTAL_PRESTAÇÕES NUMBER NULL , VALOR_PRESTAÇÃO NUMBER NULL , SALDO NUMBER NULL , NUMERO NUMBER CONSTRAINT SYS_C006489 NOT NULL , DATA_EMPRESTIMO DATE NULL , CCEMPRESTIMO_REF NUMBER NULL ); CREATE UNIQUE INDEX PK_EMPRESTIMO ON EMPRESTIMO (NUMERO ASC); ALTER TABLE EMPRESTIMO ADD CONSTRAINT PK_EMPRESTIMO PRIMARY KEY (NUMERO); CREATE INDEX FK_EMPRESTIMO_01 ON EMPRESTIMO (CCEMPRESTIMO_REF ASC); CREATE TABLE PESSOA ( ID NUMBER CONSTRAINT SYS_C006491 NOT NULL , IDPESSOA NUMBER NULL , CPF NUMBER(11) NULL ); CREATE UNIQUE INDEX PK_PESSOA ON PESSOA (ID ASC); ALTER TABLE PESSOA ADD CONSTRAINT PK_PESSOA PRIMARY KEY (ID); CREATE UNIQUE INDEX IX_PESSOA_01 ON PESSOA (CPF ASC); ALTER TABLE CLIENTE ADD (CONSTRAINT FK_CLIENTE_01 FOREIGN KEY (PK_PESSOA) REFERENCES PESSOA (ID));

137

ALTER TABLE CONTACORRENTE ADD (CONSTRAINT FK_CONTACORRENTE_01 FOREIGN KEY (AGENCIA_REF) REFERENCES AGENCIA (NUMERO)); ALTER TABLE CONTACORRENTE ADD (CONSTRAINT FK_CONTACORRENTE_02 FOREIGN KEY (CLIENTE_TITULAR) REFERENCES CLIENTE (ID)); ALTER TABLE CONTACORRENTE ADD (CONSTRAINT FK_CONTACORRENTE_03 FOREIGN KEY (CLIENTE_CONJUNTA) REFERENCES CLIENTE (ID)); ALTER TABLE EMPRESTIMO ADD (CONSTRAINT FK_EMPRESTIMO_01 FOREIGN KEY (CCEMPRESTIMO_REF) REFERENCES CONTACORRENTE (ID));

2. Script para criação do banco de dados da área intermediária:

CREATE TABLE CLIENTES ( CPF NUMBER NULL , NOME VARCHAR2(100 BYTE) NULL , DTINIVALIDADE DATE NULL , DTFIMVALIDADE DATE NULL , ROWIND NUMBER NULL , IDCLIENTE NUMBER CONSTRAINT SYS_C006513 NOT NULL , TIPOCLIENTE VARCHAR2(2 BYTE) NULL ); CREATE UNIQUE INDEX PK_CLIENTES ON CLIENTES (IDCLIENTE ASC); ALTER TABLE CLIENTES ADD CONSTRAINT PK_CLIENTES PRIMARY KEY (IDCLIENTE); CREATE UNIQUE INDEX IX_CLIENTES_01 ON CLIENTES (CPF ASC); CREATE TABLE EMPRESTIMOS ( VALOR_TOTAL NUMBER NULL , SALDO_ATUAL NUMBER NULL , VALOR_PAGO NUMBER NULL , IDEMPRESTIMO NUMBER CONSTRAINT SYS_C006521 NOT NULL , SALDO_REAL NUMBER NULL , TIPOEMPRESTIMO VARCHAR2(100 BYTE) NULL , CLIENTESPK NUMBER NULL , TEMPOPK NUMBER NULL ); CREATE UNIQUE INDEX PK_EMPRESTIMOS ON EMPRESTIMOS (IDEMPRESTIMO ASC); ALTER TABLE EMPRESTIMOS ADD CONSTRAINT PK_EMPRESTIMOS PRIMARY KEY (IDEMPRESTIMO); CREATE TABLE TEMPO (

138

TIMEID NUMBER CONSTRAINT SYS_C006517 NOT NULL , YEAR NUMBER(4) NULL , MONTH NUMBER(2) NULL , QUARTER NUMBER(1) NULL , WEEK NUMBER(2) NULL ); CREATE UNIQUE INDEX PK_TEMPO ON TEMPO (TIMEID ASC); ALTER TABLE TEMPO ADD CONSTRAINT PK_TEMPO PRIMARY KEY (TIMEID); CREATE INDEX IX_TEMPO_01 ON TEMPO (YEAR ASC,MONTH ASC,QUARTER ASC,WEEK ASC); ALTER TABLE EMPRESTIMOS ADD (CONSTRAINT FK_EMPRESTIMOS_01 FOREIGN KEY (CLIENTESPK) REFERENCES CLIENTES (IDCLIENTE)); ALTER TABLE EMPRESTIMOS ADD (CONSTRAINT FK_EMPRESTIMOS_02 FOREIGN KEY (TEMPOPK) REFERENCES TEMPO (TIMEID));

O equipamento utilizado para realização destes testes foi um Notebook Dell Vostro

1510 com memória e processador apresentados na figura 75.

Figura 75: Características físicas do equipamento usado nos testes

A versão do banco de dados utilizada se encontra registrada na figura 76 a seguir.

139

Figura 76: SQL*Plus com versão do Oracle

140

Apêndice VI

EXEMPLOS DE MODIFICAÇÕES NO

MODELO DE OBJETOS Neste apêndice serão realizados alguns experimentos de modificação nos modelos

UML da Poc para avaliarmos as conseqüentes modificações no código gerado pelo

cartucho MDA.

Na figura 77 estão presentes dois trechos do modelo de OLTP da Poc: o original e

o modificado. No modelo original encontra-se a entidade Pessoa com uma coluna CPF

que deve ser transferida para a coluna CPF da entidade Clientes (DW) e para a coluna

ClientesPK da entidade Empréstimos (DW), de acordo com os estereótipos e valores

etiquetados registrados na imagem. O modelo modificado também apresenta um

atributo CPF sendo associado à entidade Clientes (DW) e à entidade Empréstimos

(DW), no entanto, este atributo não mais se encontra na entidade Pessoa e sim,

diretamente, na entidade Cliente. A entidade Pessoa foi removida do modelo OLTP

não mais estabelecendo relacionamento com Cliente.

A partir destas modificações, tanto o código de carga para Clientes quanto o código

para carga de Empréstimo sofrerão modificações, as quais serão apresentadas nas

figuras 78 e 79. O novo código é gerado para tornar-se aderente às modificações

infligidas ao modelo. Desta forma, quando o banco de dados for modificado, a nova

aplicação já estará pronta para execução.

141

Figura 77: Trecho do modelo OLTP antes e depois da modificação

Obs.: o desenho da entidade Pessoa (versão original) e da entidade Cliente

(versão modificada) foram condensados para melhor visualização das informações.

A partir destas modificações, o código gerado para a carga de Clientes torna-se

mais simples uma vez que não há mais necessidade de se estabelecer qualquer

relacionamento com Pessoa. Observe a diferença de resultado na figura 78. O

comando Select original obtinha os dados de duas tabelas: Pessoa e Cliente. O

segundo comando Select do obtém ambas as informações diretamente de Cliente.

142

Figura 78: Trecho para carga de Clientes antes e depois da modificação

O código da figura 79 representa a carga inicial na tabela Empréstimos antes e

depois da modificação no modelo OLTP. Pode-se observar que o join existente com

Pessoa foi removido do comando Select criado para a obtenção dos dados para carga.

Figura 79: Trecho para carga de Emprestimos antes e depois da modificação

143

A segunda etapa da modificação no modelo OLTP indica, pela figura 80, que foi

acrescentado um novo relacionamento à Cliente representando a localização

geográfica do mesmo. Para a identificação destas informações foram acrescentadas

as tabelas Cidades e Estados. Uma vez que o modelo desenvolvido para o ambiente

DW segue o padrão “estrela” (onde cada dimensão somente se relaciona com Fatos),

foram acrescidas duas colunas nomeCidade e nomeEstado. Isto significa que na

operação de carga da tabela Clientes (DW) também devem ser obtidos os dados

relativos a nome da cidade e nome do estado nas tabelas Cidades e Estados,

respectivamente.

Figura 80: Segunda modificação no modelo OLTP e trecho do DW afetado

Na figura 81 encontram-se os trechos de código da operação de carga na tabela

Clientes (DW) após a primeira modificação (sem qualquer operação de Join) e após a

segunda modificação. Pode-se observar no segundo trecho que o cartucho identificou

o relacionamento presente no modelo OLTP e estabeleceu corretamente duas

operações de Join: com a tabela Cidades e com a tabela Estados. Estas operações

permitiram o preenchimento das novas colunas (nomeCidade e nomeEstado)

presentes na tabela Clientes (DW).

144

Figura 81: Trecho da operação de carga resultante da modificação 2

A terceira etapa da modificação (representada na figura 82) indica que o atributo

nomeCidade não mais seria necessário ao modelo DW. Desta forma, na entidade

Cidades foi retirado o estereótipo AttrOLTP juntamente com seus respectivos valores

etiquetados, inibindo a transferência de informações para Clientes (DW). No entanto, a

entidade Estados não foi modificada, isto é, o nome do estado continuou a ser

transferido, normalmente, para Clientes (DW). No trecho apresentado do modelo DW

pode-se observar que o atributo nomeEstado foi removido da entidade Clientes.

Estas mudanças trazem uma complexidade maior para o gerador de código uma

vez que não existe um relacionamento direto entre a entidade Estados e a entidade

Cliente. O cartucho deverá perceber que a entidade Cidades estabelece o

relacionamento necessário para a navegação com Estados. Na figura 83 encontra-se

o trecho de código resultante após as modificações introduzidas e a solução dada pelo

cartucho para atingir o resultado desejado.

145

Figura 82: Terceira modificação no modelo OLTP e trecho do DW afetado

A figura 83 a seguir mostra que o cartucho estabeleceu com sucesso o

relacionamento com a tabela Estados através da tabela Cidades, porém somente

obteve a coluna nomeEstado necessária à carga em Clientes.

146

Figura 83: Trecho da operação de carga resultante da modificação 3

Com estas modificações pudemos observar que o cartucho desenvolvido identifica

as mudanças ocorridas no modelo OLTP gerando o código necessário para a carga no

ambiente DW antes mesmo destas modificações serem realizadas no banco de dados.

Esta característica permite que seja feita por parte do modelador, assim como pelo

DBA, uma análise do impacto trazido pela modificação nas rotinas de carga

possibilitando a criação de índices, ajustes de memória ou quaisquer outras

modificações que se façam necessárias aos ambientes origem e destino, antecipando

e minimizando problemas no ambiente de produção.

147

Apêndice VII

ARQUIVOS DE ESPECIFICAÇÃO Neste apêndice serão listados os arquivos de especificação para um cartucho MDA.

Os elementos modificados em cada um dos arquivos para a prova de conceito serão

destacados e comentados. Os arquivos de configuração são:

• Cartridge.xml – O núcleo (core) do AndroMDA usa este arquivo para

selecionar e/ou descobrir as capacidades do cartucho: os suportes a

metafacades, os estereótipos, as referências (outlets), os modelos (templates),

as propriedades (property references), etc. O descritor do cartucho deve residir

no subdiretório META-INF/andromda e deve ser nomeado cartridge.xml

(ANDROMDA, 2011).

• Metafacades.xml – Descritor dos metafacades. É usado para especificar os

metafacades para o metamodelo correspondente (UML 1.4, etc.). Este descritor

também deve residir no subdiretório META-INF/andromda e deve ser nomeado

metafacades.xml (ANDROMDA, 2011).

• Namespace.xml – Uma vez que um cartucho é um componente do

namespace, ele deve ser registrado dentro de um descritor de namespaces.

Este descritor é o que permite que o namespace do cartucho seja "descoberto"

no classpath. Este descritor de namespaces também registra o cartucho no

núcleo (core) do AndroMDA. Este descritor também deve residir no subdiretório

148

META-INF/andromda e deve ser nomeado namespace.xml (ANDROMDA,

2011).

• Profile.xml – Este arquivo de configuração XML (que é normalmente localizado

em META-INF/andromda/profile.xml juntamente com os demais arquivos de

configuração - cartridge.xml, metafacades.xml e namespace.xml) permite que

alguém usando AndroMDA mapeie os estereótipos, os tagged values, e tipos de

dados para qualquer nome que ele ou ela queira sem ter de alterar qualquer

código (ANDROMDA, 2011).

OBS: Todos os arquivos serão listados com letra Courier New (tamanho 8) por se

tratar de código.

1.Cartridge.xml <cartridge> <templateEngine className="org.andromda.templateengines.velocity.VelocityTemplateEngine"> <macrolibrary name="templates/hibernate/hibernate.java.vm"/> <macrolibrary name="templates/hibernate2/hibernate.hbm.xml.vm"/> <macrolibrary name="templates/hibernate3/hibernate.hbm.xml.vm"/>  </templateEngine>  <templateObject name="stringUtils" className="org.apache.commons.lang.StringUtils"/>  <templateObject name="dwEtlUtils" className="org.andromda.cartridges.hibernate.metafacades.DwEtlMetafacadeUtils"/>

<templateObject name="hibernateUtils" className="org.andromda.cartridges.hibernate.HibernateUtils"> <property reference="hibernateVersion"/> <property reference="hibernateXMLPersistence"/> <property reference="hibernateMappingStrategy"/> </templateObject>  <property reference="securityRealm"/> <property reference="customTypesPackage"/>  <property reference="userTypesPackage"/>  <property reference="serviceLocatorName"/> <property reference="sequenceIdentifierSuffix"/> <property reference="driver"/> <property reference="username"/> <property reference="password"/> <property reference="connectionUrl"/> <property reference="dataSource"/> <property reference="schemaName"/> <property reference="hibernateDefaultCascade"/> <property reference="hibernatePoolSize"/> <property reference="hibernateTransactionFactoryClass"/> <property reference="hibernateConnectionReleaseMode"/> <property reference="hibernateTransactionManagerStrategy"/> <property reference="hibernateUserTransactionName"/>

149

<property reference="hibernateTransactionManagerLookup"/> <property reference="hibernateUseOuterJoin"/> <property reference="hibernateShowSql"/> <property reference="hibernateJndiName"/> <property reference="hibernateDialect"/> <property reference="hibernateMaxFetchDepth"/> <property reference="hibernateJdbcFetchSize"/> <property reference="hibernateJdbcBatchSize"/> <property reference="hibernateJdbcUseScrollableResultSet"/> <property reference="hibernateJdbcUseStreamsForBinary"/> <property reference="hibernateHbm2DDLAuto"/> <property reference="hibernateQuerySubstitutions"/> <property reference="hibernateEnableCache"/> <property reference="hibernateEnableAssociationsCache"/> <property reference="hibernateEhCacheDiskStore"/> <property reference="hibernateEnableDistributedCache"/> <property reference="hibernateDistributedCacheMulticastAddress"/> <property reference="hibernateDistributedCacheMulticastPort"/> <property reference="hibernateDistributedCacheSocketTimeout"/> <property reference="hibernateCacheProvider"/> <property reference="hibernateQueryCacheFactory"/> <property reference="xmlEncoding"/> <property reference="generateEntityEqualsAndHashCode"/> <property reference="hibernateProxy"/>  <property reference="hibernateQueryFactory"/> <property reference="toDoTag"/> <property reference="typeSafeEnumsEnabled"/>   <property reference="scriptName"/> <property reference="loadType"/> <property reference="sourceDir"/> <property reference="sourcePrefix"/> <property reference="commitCount"/> <property reference="datastagePrefixName"/> <property reference="oltpPrefixName"/> <property reference="dwPrefixName"/> <property reference="datastageType"/> <property reference="actionPrefixName"/>  <condition name="mapSubclassesInSeparateFile">$hibernateUtils.mapSubclassesInSeparateFile</condition> <condition name="typeSafeEnumsEnabled">$typeSafeEnumsEnabled.equalsIgnoreCase("true")</condition>    <template path="templates/hibernate2/ejb/HibernateEntityFactory.vsl" outputPattern="{0}/{1}Factory.java" outlet="session-beans" overwrite="true"> <modelElements variable="entity"> <modelElement> <type name="org.andromda.cartridges.hibernate.metafacades.HibernateEntity"> <property name="version">2</property> </type> </modelElement> </modelElements> </template> <template path="templates/hibernate2/hibernate.cfg.xml.vsl" outputPattern="hibernate.cfg.xml" outlet="configuration" overwrite="true"

150

outputToSingleFile="true" outputOnEmptyElements="false"> <modelElements variable="entities"> <modelElement> <type name="org.andromda.cartridges.hibernate.metafacades.HibernateEntity"> <property name="requiresMapping"/> <property name="version">2</property> </type> </modelElement> </modelElements> </template> <template path="templates/hibernate2/hibernate.hbm.xml.vsl" outputPattern="$generatedFile" outlet="entity-mappings" overwrite="true"> <modelElements variable="entity"> <modelElement> <type name="org.andromda.cartridges.hibernate.metafacades.HibernateEntity"> <property name="requiresMapping"/> <property name="version">2</property> </type> </modelElement> </modelElements> </template> <template path="templates/hibernate2/HibernateEnumeration.vsl" outputPattern="$generatedFile" outlet="user-types" overwrite="true"> <modelElements variable="enumeration"> <modelElement> <type name="org.andromda.metafacades.uml.EnumerationFacade"> <property name="version">2</property> </type> </modelElement> </modelElements> </template>  <template path="templates/hibernate3/ejb/HibernateEntityFactory.vsl" outputPattern="{0}/{1}Factory.java" outlet="session-beans" overwrite="true"> <modelElements variable="entity"> <modelElement> <type name="org.andromda.cartridges.hibernate.metafacades.HibernateEntity"> <property name="version">3</property> </type> </modelElement> </modelElements> </template> <template path="templates/hibernate3/hibernate.cfg.xml.vsl" outputPattern="hibernate.cfg.xml" outlet="configuration" overwrite="true" outputToSingleFile="true" outputOnEmptyElements="false"> <modelElements variable="entities"> <modelElement> <type name="org.andromda.cartridges.hibernate.metafacades.HibernateEntity"> <property name="requiresMapping"/> <property name="version">3</property> </type> </modelElement> </modelElements> </template>

151

 <template path="templates/DwEtlEntity.vsl" outputPattern="$generatedFile" outlet="entities" overwrite="true" outputToSingleFile="true" outputOnEmptyElements="true"> <modelElements variable="entities"> <modelElement> <type name="org.andromda.cartridges.hibernate.metafacades.DwEtlEntity"/> </modelElement> </modelElements> </template>

<template path="templates/hibernate3/hibernate.hbm.xml.vsl" outputPattern="$generatedFile" outlet="entity-mappings" overwrite="true"> <modelElements variable="entity"> <modelElement> <type name="org.andromda.cartridges.hibernate.metafacades.HibernateEntity"> <property name="requiresMapping"/> <property name="version">3</property> </type> </modelElement> </modelElements> </template> <template path="templates/hibernate3/HibernateEnumeration.vsl" outputPattern="$generatedFile" outlet="user-types" overwrite="true"> <modelElements variable="enumeration"> <modelElement> <type name="org.andromda.metafacades.uml.EnumerationFacade"> <property name="version">3</property> <property name="typeSafe">false</property> </type> </modelElement> </modelElements> </template> <template path="templates/hibernate3/hibernate.cfg.xml.vsl" outputPattern="hibernate.cfg.xml" outlet="configuration" overwrite="true" outputToSingleFile="true" outputOnEmptyElements="false"> <modelElements variable="entities"> <modelElement> <type name="org.andromda.cartridges.hibernate.metafacades.HibernateEntity"> <property name="requiresMapping"/> <property name="version">3</property> </type> </modelElement> </modelElements> </template> <template path="templates/hibernate3/usertypes/HibernateEnumType.vsl" outputPattern="$generatedFile" outlet="user-types" overwrite="true" outputToSingleFile="true" outputOnEmptyElements="false"> <modelElements variable="enumeration"> <modelElement> <type name="org.andromda.metafacades.uml.EnumerationFacade"> <property name="version">3</property> <property name="typeSafe">true</property>

152

</type> </modelElement> </modelElements> </template>  <template path="templates/hibernate/HibernateEntityPK.vsl" outputPattern="$generatedFile" outlet="entities" overwrite="true"> <modelElements variable="entity"> <modelElement> <type name="org.andromda.cartridges.hibernate.metafacades.HibernateEntity"> <property name="compositeIdentifier">true</property> </type> </modelElement> </modelElements> </template> <template path="templates/hibernate/HibernateEmbeddedValue.vsl" outputPattern="$generatedFile" outlet="entities" overwrite="true"> <modelElements variable="embeddedValue"> <modelElement> <type name="org.andromda.cartridges.hibernate.metafacades.HibernateEmbeddedValue"/> </modelElement> </modelElements> </template> <template path="templates/hibernate/HibernateEmbeddedValueImpl.vsl" outputPattern="$generatedFile" outlet="entity-impls" overwrite="false"> <modelElements variable="embeddedValue"> <modelElement> <type name="org.andromda.cartridges.hibernate.metafacades.HibernateEmbeddedValue"/> </modelElement> </modelElements> </template> <template path="templates/hibernate/HibernateEntity.vsl" outputPattern="$generatedFile" outlet="entities" overwrite="true"> <modelElements variable="entity"> <modelElement> <type name="org.andromda.cartridges.hibernate.metafacades.HibernateEntity"/> </modelElement> </modelElements> </template> <template path="templates/hibernate/HibernateEntityImpl.vsl" outputPattern="$generatedFile" outlet="entities" overwrite="true"> <modelElements variable="entity"> <modelElement> <type name="org.andromda.cartridges.hibernate.metafacades.HibernateEntity"> <property name="businessOperationsPresent">false</property> </type> </modelElement> </modelElements> </template> <template path="templates/hibernate/HibernateEntityImpl.vsl"

153

outputPattern="$generatedFile" outlet="entity-impls" overwrite="false"> <modelElements variable="entity"> <modelElement> <type name="org.andromda.cartridges.hibernate.metafacades.HibernateEntity"> <property name="businessOperationsPresent"/> </type> </modelElement> </modelElements> </template> <template path="templates/hibernate/usertypes/HibernateByteBlobType.vsl" outputPattern="$generatedFile" outlet="user-types" overwrite="true"/> <template path="templates/hibernate/usertypes/HibernateStringClobType.vsl" outputPattern="$generatedFile" outlet="user-types" overwrite="true"/> <template path="templates/hibernate/ejb/ejb-jar.xml.vsl" outputPattern="META-INF/ejb-jar.xml" outlet="session-beans" overwrite="true" outputToSingleFile="true" outputOnEmptyElements="false"> <modelElements variable="services"> <modelElement> <type name="org.andromda.metafacades.uml.Service"/> </modelElement> </modelElements> </template> <template path="templates/hibernate/ejb/jboss.xml.vsl" outputPattern="META-INF/jboss.xml" outlet="session-beans" overwrite="true" outputToSingleFile="true" outputOnEmptyElements="false"> <modelElements variable="services"> <modelElement> <type name="org.andromda.metafacades.uml.Service"/> </modelElement> </modelElements> </template> <template path="templates/hibernate/ejb/HibernateSessionEJBLocator.vsl" outputPattern="$generatedFile" outlet="session-beans" overwrite="true" outputToSingleFile="true" outputOnEmptyElements="false"> <modelElements variable="services"> <modelElement> <type name="org.andromda.metafacades.uml.Service"/> </modelElement> </modelElements> </template> <template path="templates/hibernate/ejb/HibernateSessionBean.vsl" outputPattern="{0}/{1}Bean.java" outlet="session-beans" overwrite="true"> <modelElements variable="service"> <modelElement> <type name="org.andromda.metafacades.uml.Service"/> </modelElement> </modelElements>

154

</template> <template path="templates/hibernate/ejb/HibernateSessionBeanImpl.vsl" outputPattern="{0}/{1}BeanImpl.java" outlet="session-impls" overwrite="false"> <modelElements variable="service"> <modelElement> <type name="org.andromda.metafacades.uml.Service"/> </modelElement> </modelElements> </template> <template path="templates/hibernate/ejb/HibernateSession.vsl" outputPattern="$generatedFile" outlet="session-beans" overwrite="true"> <modelElements variable="service"> <modelElement> <type name="org.andromda.metafacades.uml.Service"/> </modelElement> </modelElements> </template> <template path="templates/hibernate/ejb/HibernateSessionHome.vsl" outputPattern="$generatedFile" outlet="session-beans" overwrite="true"> <modelElements variable="service"> <modelElement> <type name="org.andromda.metafacades.uml.Service"/> </modelElement> </modelElements> </template> <template path="templates/hibernate/ejb/HibernateUtils.vsl" outputPattern="$generatedFile" outlet="session-beans" overwrite="true"/> <template path="templates/hibernate/ehcache.xml.vsl" outputPattern="ehcache.xml" outlet="cache" overwrite="true" outputToSingleFile="true" outputOnEmptyElements="false"> <modelElements variable="entities"> <modelElement> <type name="org.andromda.metafacades.uml.Entity"/> </modelElement> </modelElements> </template>  </cartridge>

155

2.Metafacades.xml <?xml version="1.0" encoding="ISO-8859-1" ?>  <metafacades> <property reference="hibernateVersion"/> <property reference="hibernateXMLPersistence"/> <property reference="hibernateXMLPersistIDAsAttribute"/> <property reference="entityNamePattern"/> <property reference="entityImplementationNamePattern"/> <property reference="defaultHibernateGeneratorClass"/> <property reference="hibernateDefaultCascade"/> <property reference="hibernateCompositionCascade"/> <property reference="hibernateAggregationCascade"/> <property reference="hibernateEntityCache"/> <property reference="hibernateEnableDistributedCache"/> <property reference="hibernateEntityDynamicInsert"/> <property reference="hibernateEntityDynamicUpdate"/> <property reference="hibernateProxy"/> <property reference="hibernateQueryUseNamedParameters"/> <property reference="hibernateInheritanceStrategy"/> <property reference="hibernateUseQueryCache"/> <property reference="ehCacheMaxElementsInMemory"/> <property reference="ehCacheEternal"/> <property reference="ehCacheTimeToIdleSeconds"/> <property reference="ehCacheTimeToLiveSeconds"/> <property reference="ehCacheOverflowToDisk"/> <property reference="compositionDefinesEagerLoading"/> <property reference="ejbJndiNamePrefix"/> <property reference="ejbViewType"/> <property reference="hibernateAssociationCollectionType"/> <property reference="hibernateAssociationSortType"/> <property reference="enumerationNamePattern"/> <property reference="hibernateQueryUseSpecializedSetters"/> <property reference="versionProperty"/>  <property reference="scriptName"/> <property reference="loadType"/> <property reference="sourceDir"/> <property reference="sourcePrefix"/> <property reference="commitCount"/> <property reference="datastagePrefixName"/> <property reference="oltpPrefixName"/> <property reference="dwPrefixName"/> <property reference="datastageType"/> <property reference="actionPrefixName"/>

 <metafacade class="org.andromda.cartridges.hibernate.metafacades.DwEtlEntityLogicImpl" contextRoot="true"> <mapping> <stereotype>ENTITYDW</stereotype> </mapping> </metafacade> <metafacade class="org.andromda.cartridges.hibernate.metafacades.DwEtlEntityLogicImpl" contextRoot="true"> <mapping> <stereotype>ENTITYOLTP</stereotype> </mapping> </metafacade>

 <metafacade class="org.andromda.cartridges.hibernate.metafacades.DwEtlEntityTransformLogicImpl" contextRoot="true"> <mapping> <stereotype>ENTITYTRANSFORM</stereotype> </mapping> </metafacade>

156

 <metafacade class="org.andromda.cartridges.hibernate.metafacades.DwEtlActionStateLogicImpl" contextRoot="true"> <mapping> <stereotype>ACTIONSPLIT</stereotype> </mapping> </metafacade>

<metafacade class="org.andromda.cartridges.hibernate.metafacades.DwEtlActionStateLogicImpl" contextRoot="true"> <mapping> <stereotype>ACTIONCONSTANT</stereotype> </mapping> </metafacade>

<metafacade class="org.andromda.cartridges.hibernate.metafacades.DwEtlActionStateLogicImpl" contextRoot="true"> <mapping> <stereotype>ACTIONCONVERSION</stereotype> </mapping> </metafacade> <metafacade class="org.andromda.cartridges.hibernate.metafacades.DwEtlActionStateLogicImpl" contextRoot="true"> <mapping> <stereotype>ACTIONDERIVATION</stereotype> </mapping> </metafacade> <metafacade class="org.andromda.cartridges.hibernate.metafacades.DwEtlActionStateLogicImpl" contextRoot="true"> <mapping> <stereotype>ACTIONFILTER</stereotype> </mapping> </metafacade>

<metafacade class="org.andromda.cartridges.hibernate.metafacades.DwEtlEntityAttributeLogicImpl"> <mapping> <context>org.andromda.cartridges.hibernate.metafacades.DwEtlEntity</context> </mapping> </metafacade> <metafacade class="org.andromda.cartridges.hibernate.metafacades.DwEtlEntityAttributeLogicImpl"> <mapping> <context>org.andromda.cartridges.hibernate.metafacades.DwEtlEntity</context> </mapping> </metafacade> <metafacade class="org.andromda.cartridges.hibernate.metafacades.DwEtlAssocEndLogicImpl"> <mapping> <context>org.andromda.cartridges.hibernate.metafacades.DwEtlEntity</context> </mapping> </metafacade> <metafacade class="org.andromda.cartridges.hibernate.metafacades.HibernateEntityLogicImpl" contextRoot="true"> <mapping> <stereotype>ENTITY</stereotype> </mapping> <property reference="hibernateMappingStrategy"/> <property reference="defaultEntityDiscriminatorColumn"/> <property reference="defaultEntityDiscriminatorType"/> </metafacade>

157

<metafacade class="org.andromda.cartridges.hibernate.metafacades.HibernateAssociationEndLogicImpl"> <mapping> <property name="type.hibernateEntityMetaType"/> </mapping> <property reference="hibernateAssociationEndOuterJoin"/> <property reference="listTypeImplementation"/> <property reference="setTypeImplementation"/> <property reference="mapTypeImplementation"/> <property reference="bagTypeImplementation"/> <property reference="specificCollectionInterfaces"/> <property reference="defaultCollectionInterface"/> <property reference="associationEndCollectionIndexName"/> <property reference="associationEndCollectionIndexType"/> </metafacade> <metafacade class="org.andromda.cartridges.hibernate.metafacades.HibernateAssociationLogicImpl"> <mapping> <property name="associationEndA.hibernateAssociationEndMetaType"/> </mapping> <property reference="hibernateAssociationCache"/> </metafacade> <metafacade class="org.andromda.cartridges.hibernate.metafacades.HibernateFinderMethodLogicImpl" contextRoot="true"> <mapping> <stereotype>FINDER_METHOD</stereotype> <context>org.andromda.cartridges.hibernate.metafacades.HibernateEntity</context> </mapping> </metafacade> <metafacade class="org.andromda.cartridges.hibernate.metafacades.HibernateFinderMethodLogicImpl" contextRoot="true"> <mapping> <property name="owner.hibernateEntityMetaType"/> <property name="query"/> </mapping> </metafacade> <metafacade class="org.andromda.cartridges.hibernate.metafacades.HibernateServiceOperationLogicImpl"> <mapping> <context>org.andromda.cartridges.hibernate.metafacades.HibernateService</context> </mapping> <property reference="serviceOperationTransactionType"/> </metafacade> <metafacade class="org.andromda.cartridges.hibernate.metafacades.HibernateServiceOperationLogicImpl"> <mapping> <property name="owner.interface"/> </mapping> <property reference="serviceOperationTransactionType"/> </metafacade> <metafacade class="org.andromda.cartridges.hibernate.metafacades.HibernateFinderMethodArgumentLogicImpl"> <mapping> <context>org.andromda.cartridges.hibernate.metafacades.HibernateFinderMethod</context> </mapping> </metafacade> <metafacade class="org.andromda.cartridges.hibernate.metafacades.HibernateServiceLogicImpl" contextRoot="true"> <mapping> <stereotype>SERVICE</stereotype> </mapping> </metafacade> <metafacade class="org.andromda.cartridges.hibernate.metafacades.HibernateTypeLogicImpl"> <property reference="hibernateTypeMappingsUri"/> </metafacade>

158

<metafacade class="org.andromda.cartridges.hibernate.metafacades.HibernateEnumerationLogicImpl"> <mapping> <stereotype>ENUMERATION</stereotype> </mapping> </metafacade> <metafacade class="org.andromda.cartridges.hibernate.metafacades.HibernateEntityAttributeLogicImpl"> <mapping> <context>org.andromda.cartridges.hibernate.metafacades.HibernateEntity</context> </mapping> <property reference="hibernateTypeMappingsUri"/> </metafacade> <metafacade class="org.andromda.cartridges.hibernate.metafacades.HibernateEmbeddedValueLogicImpl" contextRoot="true"> <mapping> <stereotype>EMBEDDED_VALUE</stereotype> </mapping> <property reference="embeddedValueImplementationNamePattern"/> </metafacade> <metafacade class="org.andromda.cartridges.hibernate.metafacades.HibernateEntityAttributeLogicImpl"> <mapping> <context>org.andromda.cartridges.hibernate.metafacades.HibernateEmbeddedValue</context> </mapping> <property reference="sqlMappingsUri"/> <property reference="jdbcMappingsUri"/> </metafacade> </metafacades>

3. Namespace.xml <?xml version="1.0" encoding="UTF-8"?> <namespace name="hibernate"> <components> <component name="cartridge"> <path>META-INF/andromda/cartridge.xml</path> </component> <component name="metafacades"> <path>META-INF/andromda/metafacades.xml</path> </component> <component name="profile"> <path>META-INF/andromda/profile.xml</path> </component> </components> <properties>  <propertyGroup name="Outlets"> <documentation> Defines the locations to which output is generated. </documentation> <property name="entities"> <documentation> The directory to which hibernate entities are generated. Please <strong>NOTE</strong> that the entity implementation classes will also be generated to this location when <strong>no operations</strong> are present on the entity with <em>instance scope</em>. </documentation> </property> <property name="entity-impls"> <documentation> The location to which hibernate entity implementation files are generated. Please <strong>NOTE</strong> that the entity implementation classes will be generated to the <em>entities</em> outlet when <strong>no operations</strong> are present on the entity with <em>instance scope</em>. </documentation>

159

</property> <property name="entity-mappings"> <documentation> The location to which hibernate entity mapping files are generated, these are the ones with the <code>.hbm.xml</code> extension. </documentation> </property> <property name="user-types"> <documentation> The location to which hibernate enumeration user-types are generated. This includes String CLOB, BLOB and enumeration user-types. </documentation> </property> <property name="session-beans" required="false"> <documentation> The directory to which Session EJB service wrappers are generated. If this property is not specified, Session EJB service wrappers will not be generated. </documentation> </property> <property name="session-impls" required="false"> <documentation> The directory to which Session Bean implementation files are generated. </documentation> </property> <property name="configuration" required="false"> <documentation> The directory to which the hibernate.cfg.xml file is generated. </documentation> </property> <property name="cache" required="false"> <documentation> The directory to which the ehcache.xml file is generated. </documentation> </property> </propertyGroup> <propertyGroup name="Caching"> <property name="hibernateEnableCache"> <default>false</default> <documentation> Enable/disable hibernate's second level cache features for the cartridge. </documentation> </property> <property name="hibernateEnableDistributedCache"> <default>false</default> <documentation> If this property is set to true, distributed caching will be enabled. To enable distributed caching for an entity, you must set this property to true AND tag the entity using the tagged value <a href="profile.html#@andromda.hibernate.entity.cache.distributed">@andromda.hibernate.entity.cache.distributed</a> tagged value. <ul> <li>true</li> <li>false</li> </ul> </documentation> </property> <property name="hibernateDistributedCacheMulticastPort"> <default>4446</default> <documentation> The multicast port to be used for multicast group communication when using a distributed cache provider (see <a href="#hibernateEnableDistributedCache">hibernateEnableDistributedCache</a>). </documentation> </property> <property name="hibernateDistributedCacheMulticastAddress"> <default>230.0.0.1</default> <documentation>

160

The address to be used for multicast group communication when using a distributed cache provider (see <a href="#hibernateEnableDistributedCache">hibernateEnableDistributedCache</a>). </documentation> </property> <property name="hibernateDistributedCacheSocketTimeout"> <default>2000</default> <documentation> The number of seconds client sockets will wait when sending messages to this listener until they give up. </documentation> </property> <property name="hibernateEntityCache"> <default>read-write</default> <documentation> Defines the default strategy for Entities caching. Can be overwritten using the corresponding tagged value. Possible values are: <ul> <li>read-write</li> <li>nonstrict-read-write</li> <li>read-only</li> </ul> </documentation> </property> <property name="hibernateAssociationCache"> <default>read-write</default> <documentation> Defines the default strategy for associations between Entities caching. Can be overwrited with the corresponding tagged value. Possible values are: <ul> <li>read-write</li> <li>nonstrict-read-write</li> <li>read-only</li> </ul> </documentation> </property> <property name="hibernateUseQueryCache"> <default>false</default> <documentation> The default query cache usage. Can be overwritten using <a href="profile.html#@andromda_hibernate_query_useCache">@andromda.hibernate.query.useCache</a>. Possible values are: <ul> <li>true</li> <li>false</li> </ul> </documentation> </property> <property name="hibernateEnableAssociationsCache"> <default>false</default> <documentation> Enable/disable Hibernate's second level cache feature for entity associations. Please <strong>NOTE</strong> that hibernateEnableCache should also be enabled when specifying this property. </documentation> </property> <property name="hibernateEhCacheDiskStore"> <default>java.io.tmpdir</default> <documentation> Defines the path to the directory where cache files will be created </documentation> </property> <property name="hibernateCacheProvider"> <default>net.sf.hibernate.cache.EhCacheProvider</default> <documentation> Defines Hibernate Cache Provider implementation class. Possible values for Hibernate2 are: <ul> <li>net.sf.hibernate.cache.EhCacheProvider</li>

161

<li>net.sf.hibernate.cache.HashtableCacheProvider</li> <li>net.sf.hibernate.cache.JCSCacheProvider</li> <li>net.sf.hibernate.cache.SwarmCacheProvider</li> <li>net.sf.hibernate.cache.TreeCacheProvider</li> <li>net.sf.hibernate.cache.OSCacheProvider</li> </ul> Possible values for Hibernate3 are: <ul> <li>org.hibernate.cache.EhCacheProvider</li> <li>org.hibernate.cache.HashtableCacheProvider</li> <li>org.hibernate.cache.JCSCacheProvider</li> <li>org.hibernate.cache.SwarmCacheProvider</li> <li>org.hibernate.cache.TreeCacheProvider</li> <li>org.hibernate.cache.OSCacheProvider</li> </ul> </documentation> </property> <property name="hibernateQueryCacheFactory"> <default>net.sf.hibernate.cache.StandardQueryCacheFactory</default> <documentation> Defines Hibernate Query Cache Factory implementation class. Possible value for Hibernate2 is: <ul> <li>net.sf.hibernate.cache.StandardQueryCacheFactory</li> </ul> Possible value for Hibernate3 is: <ul> <li>org.hibernate.cache.StandardQueryCacheFactory</li> </ul> </documentation> </property> <property name="hibernateConnectionReleaseMode" required="false"> <documentation> Specify when Hibernate should release JDBC connections. By default, a JDBC connection is held until the session is explicitly closed or disconnected. For an application server JTA datasource, you should use after_statement to aggressively release connections after every JDBC call. For a non-JTA connection, it often makes sense to release the connection at the end of each transaction, by using after_transaction. auto will choose after_statement for the JTA and CMT transaction strategies and after_transaction for the JDBC transaction strategy. <ul> Valid values are: <li>on_close</li> - default <li>after_transaction</li> <li>after_statement</li> <li>auto</li> </ul> </documentation> </property> <property name="ehCacheMaxElementsInMemory"> <default>10000</default> <documentation> Defines the default maximum number of objects that will be created in memory. </documentation> </property> <property name="ehCacheEternal"> <default>false</default> <documentation> Defines a default value for the eternal parameter. </documentation> </property> <property name="ehCacheTimeToIdleSeconds"> <default>120</default> <documentation> Defines the default time to idle for an element before it expires. </documentation> </property> <property name="ehCacheTimeToLiveSeconds"> <default>120</default> <documentation> Defines the default time to live for an element before it expires.

162

</documentation> </property> <property name="ehCacheOverflowToDisk"> <default>true</default> <documentation> Defines the default value for the overflow to disk property. </documentation> </property> </propertyGroup> <propertyGroup name="JDBC"> <property name="driver" required="false"> <documentation> JDBC Driver to make database connection, this should be a fully qualified Java class name. </documentation> </property> <property name="username" required="false"> <documentation> The database user login name. </documentation> </property> <property name="password" required="false"> <documentation> The database user password. </documentation> </property> <property name="connectionUrl" required="false"> <documentation> URL for the JDBC Driver to make the connection to the database. </documentation> </property> <property name="dataSource" required="false"> <documentation> JNDI name of data source to use. (would be used instead of the connection properties, driver, username, password, etc). </documentation> </property> <property name="hibernateShowSql" required="false"> <documentation> Whether or not to log SQL statements. </documentation> </property> <property name="hibernateDialect" required="false"> <documentation> SQL dialect of the database. </documentation> </property> <property name="hibernateMaxFetchDepth" required="false"> <documentation> Sets a maximum "depth" for the outer join fetch tree. Recommended values between 0 and 3 </documentation> </property> <property name="hibernateJdbcFetchSize" required="false"> <documentation> A non-zero value determines the JDBC fetch size </documentation> </property> <property name="hibernateJdbcBatchSize" required="false"> <documentation> A nonzero value enables use of JDBC2 batch updates by Hibernate. Recommended values between 5 and 30 </documentation> </property> <property name="hibernateJdbcUseScrollableResultSet" required="false"> <documentation> Whether or not to enable use of JDBC2 scrollable resultsets by Hibernate. This property is only necessary when using user supplied connections. Hibernate uses connection metadata otherwise. </documentation> </property> <property name="hibernateJdbcUseStreamsForBinary" required="false"> <documentation> Whether or not to use streams when writing / reading binary or serializable types to/from JDBC.

163

</documentation> </property> <property name="hibernateHbm2DDLAuto" required="false"> <documentation> Automatically export schema DDL to the database when the SessionFactory is created. With create-drop, the database schema will be dropped when the SessionFactory is closed explicitely. Permitted values are: <ol> <li>update</li> <li>create</li> <li>create-drop</li> <li>validate (since Hibernate 3)</li> </ol> </documentation> </property> <property name="hibernateQuerySubstitutions" required="false"> <documentation> Allows you to define new Hibernate query tokens. For example: giving this a value of <em>true=1, false=0</em> would cause the tokens true and false to be translated to integer literals in the generated SQL. </documentation> </property> <property name="sequenceIdentifierSuffix"> <default>_SEQ</default> <documentation> The suffix to use for identifier sequences. </documentation> </property> <property name="hibernateUseOuterJoin" required="false"> <documentation> Whether or not to use outer join. </documentation> </property> </propertyGroup> <propertyGroup name="Name Patterns"> <property name="entityNamePattern"> <default>{0}</default> <documentation> The pattern to use when constructing an entity name. <em>{0}</em> is used to represent the entity name in the model, so if you specified a value of <code>{0}Entity</code> all the entities generated would have a suffix of "Entity". </documentation> </property> <property name="entityImplementationNamePattern"> <default>{0}Impl</default> <documentation> The pattern to use when constructing the entity implementation name. </documentation> </property> <property name="embeddedValueImplementationNamePattern"> <default>{0}Impl</default> <documentation> The pattern to use when constructing an embedded value implementation name. </documentation> </property> <property name="enumerationNamePattern"> <default>{0}Enum</default> <documentation> The pattern to use when constructing hibernate enumerations. </documentation> </property> <property name="ejbJndiNamePrefix" required="false"> <documentation> The prefix to give to the Session EJB JNDI names (this allows the same Session EJB to be deployed multiple times in the same container) </documentation> </property> </propertyGroup> <propertyGroup name="Transactions"> <property name="serviceOperationTransactionType">

164

<default>Required</default> <documentation> The default value to use for service operations transaction types. <ul> Permitted values are: <li>NotSupported</li> <li>Supports</li> <li>Required</li> <li>RequiresNew</li> <li>Mandatory</li> <li>Never</li> </ul> <strong>NOTE:</strong> Can be overridden on a per entity basis with the <a href="profile.html#@andromda_ejb_transaction_type">@andromda.ejb.transaction.type</a> tagged value. </documentation> </property> <property name="hibernateTransactionFactoryClass"> <default>net.sf.hibernate.transaction.JTATransactionFactory</default> <documentation> The name of the hibernate transaction factory class to use. </documentation> </property> <property name="hibernateTransactionManagerStrategy" required="false"> <documentation> Strategy for obtaining the JTA TransactionManager. </documentation> </property> <property name="hibernateUserTransactionName"> <default>UserTransaction</default> <documentation> The JNDI name of the JTA UserTransaction object. </documentation> </property> <property name="hibernateTransactionManagerLookup" required="false"> <documentation> The fully qualified class name of the Hibernate TransactionFactory implementation. </documentation> </property> </propertyGroup> <propertyGroup name="Other"> <property name="hibernateVersion"> <default>2</default> <documentation> The version of Hibernate to use when generating. Allowable values are: <ul> <li>2 - Hibernate 2.x</li> <li>3 - Hibernate 3.x</li> </ul> </documentation> </property>  <property name="scriptName"> <default>CargaEtl</default> <documentation> Cartucho DwETL - nome do arquivo principal dos scripts de carga. </documentation> </property> <property name="actionPrefixName"> <default>ActivityEtl</default> <documentation> Cartucho DwETL - nome do prefixo para os arquivos dos scripts de transformação. </documentation> </property> <property name="sourceDir" required="false"> <documentation> Diretório onde os fontes das procedures de carga serão geradas. </documentation> </property> <property name="loadType"> <default>1</default> <documentation>

165

Tipo das procedures geradas. Os valores válidos são: <ul> <li>1 - carga inicial</li> <li>2 - carga incremental</li> </ul> </documentation> </property> <property name="sourcePrefix"> <default>dwETL</default> <documentation> Prefixo de todos os arquivos e procedures de carga. </documentation> </property> <property name="commitCount"> <default>1000</default> <documentation> Quantidade de linhas carregadas entre commits. </documentation> </property> <property name="datastagePrefixName"> <default>datastage</default> <documentation> Prefixo a ser usado para as tabelas no ambiente intermediário, considerando-se o uso de sinônimos para o acesso à tabela real. </documentation> </property> <property name="datastageType"> <default>fasterOLTP</default> <documentation> Tipo das procedures geradas. Os valores válidos são: <ul> <li>fasterOLTP - a carga entre OLTP e datastage traz os dados origem sem transformações. A datastage é similar ao OLTP com algumas colunas de trabalho.</li> <li>classic - a carga entre OLTP e datastage já realiza algumas transformações. A datastage é similar ao DW com algumas colunas de trabalho.</li> </ul> </documentation> </property> <property name="oltpPrefixName"> <default>OLTP</default> <documentation> Prefixo a ser usado para as tabelas no ambiente OLTP, considerando-se o uso de sinônimos para o acesso à tabela real. </documentation> </property> <property name="dwPrefixName"> <default>DW</default> <documentation> Prefixo a ser usado para as tabelas no ambiente DW, considerando-se o uso de sinônimos para o acesso à tabela real. </documentation> </property> <property name="hibernateXMLPersistence"> <default>false</default> <documentation> Set to <code>true</code> to enable Hibernate's <a href="http://www.hibernate.org/hib_docs/v3/reference/en/html/xml.html">XML persistence support</a> using dom4J. The <code>hibernateVersion</code> namespace property must be set to <code>3</code>. </documentation> </property> <property name="hibernateXMLPersistIDAsAttribute"> <default>true</default> <documentation> Set to <code>true</code> if the identifier for generated entities should be mapped to an <i>attribute</i> of the entity's XML tag, or as a separate field when <a href="http://www.hibernate.org/hib_docs/v3/reference/en/html/xml.html">XML persistence support</a> is enabled. The <code>hibernateXMLPersistence</code> namespace property must be set to <code>true</code> for this option to have meaning.

166

</documentation> </property> <property name="defaultHibernateGeneratorClass"> <default>native</default> <documentation> The default class to use for Hibernate ID generation (can be overridden on a per entity basis with the <a href="profile.html#@andromda_hibernate_generator_class">@andromda.hibernate.generator.class</a> tagged value). </documentation> </property> <property name="hibernateDefaultCascade"> <default>none</default> <documentation> The value of the <code>default-cascade</code> attribute of the hibernate entity XML mapping. </documentation> </property> <property name="hibernateCompositionCascade" required="false"> <documentation> Indicates how a UML composition should be interpreted as cascade. <ul> <li> If undefined, the cascade attribute is computed by AndroMDA in the following manner: if default-cascade is <em>save-update</em> or <em>all</em>, then cascade is <em>all</em> (0..1) or <em>all-delete-orphan</em> (many) otherwise cascade is <em>delete</em>. </li> <li> If the property IS defined, it's value is generated at each occurence of a UML composition, and the inverse side is marked with cascade="none". The value must be a valid Hibernate cascade style. You should use a cascade value which includes delete to be conform with the UML concept of a composition, e.g. <em>all-delete-orphan</em>. </li> </ul> </documentation> </property> <property name="hibernateAggregationCascade" required="false"> <documentation> Indicates how a UML aggregation should be interpreted as cascade. Possible values are are as follows: <ul> <li> If undefined, aggregation is not interpreted as a cascade value </li> <li> If the property IS defined, its value is generated at each occurence of a UML aggregation, and the inverse side is marked with <em>cascade="none"</em>. The value must be a valid Hibernate cascade style, e.g. <em>all</em>. </li> </ul> </documentation> </property> <property name="hibernateEntityDynamicInsert"> <default>false</default> <documentation> Defines the default value dynamic-insert property on entities. </documentation> </property> <property name="hibernateEntityDynamicUpdate"> <default>false</default> <documentation> Defines the default value dynamic-update property on entities. </documentation> </property>

167

<property name="hibernateProxy"> <default>false</default> <documentation> Defines if proxies will be enabled for Hibernate Entities. </documentation> </property> <property name="hibernateQueryUseNamedParameters"> <default>false</default> <documentation> Whether or not named parameters (i.e. ':someParameter') or unnamed (i.e. '?') parameters should be used in the HQL queries embedded within the model. <strong>NOTE:</strong> Does not apply to queries written in OCL. </documentation> </property> <property name="hibernateInheritanceStrategy"> <default>subclass</default> <documentation> Defines the hibernate inheritance strategy (unless overridden on an entity level by the <a href="profile.html#@andromda_hibernate_inheritance">@andromda.hibernate.inheritance</a> tagged value, can be the following possible values: <ul> <li>class - table per hierarchy.</li> <li>subclass - table per class in hierarchy.</li> <li>concrete - Table per class.</li> <li>union-subclass - Table per class (Only Hibernate 3).</li> <li> interface - Root class is defined as an interface and the attributes remapped to the subclasses. This is useful in the concrete case because it has limitations in the associations. </li> </ul> </documentation> </property> <property name="hibernateMappingStrategy"> <default>hierarchy</default> <documentation> Denotes whether or not subclasses should be mapped into the same <code>.hbm.xml</code> file or in a separate one. <ul> <li>Set this value to <code>subclass</code> when you want to have a mapping file per entity</li> <li>The default is <code>hierarchy</code> which will render a mapping file per subclass</li> </ul> </documentation> </property> <property name="defaultEntityDiscriminatorColumn"> <default>class</default> <documentation> The default name of the <code>discriminator-column</code> on the hibernate entity XML mapping. </documentation> </property> <property name="defaultEntityDiscriminatorType"> <default>string</default> <documentation> The default type of the <code>discriminator-column</code> of the hibernate entity XML mapping. </documentation> </property> <property name="compositionDefinesEagerLoading"> <default>true</default> <documentation> Allows you to turn on/off whether or not composite associations will define eager loading. </documentation> </property> <property name="ejbViewType"> <default>local</default> <documentation> If EJBs are being used, this specifies the default view type for the EJB interfaces. Can be either <em>local</em>

168

or <code>remote</code>. </documentation> </property> <property name="hibernateAssociationCollectionType"> <default>set</default> <documentation> Used to define the default mapping for hibernate collections. </documentation> </property> <property name="hibernateAssociationSortType"> <default>unsorted</default> <documentation> Used to define how elements will be sorted within the collection defined by the association. (Only available for maps and sets). </documentation> </property> <property name="hibernateQueryUseSpecializedSetters"> <default>false</default> <documentation> Defines if the finder setters method for parameters will use "setParameter" for all parameters (by default), or a specialized setter (setDate, setBoolean, etc.) in case the parameter type has it's own setter method. </documentation> </property> <property name="versionProperty" required="false"> <documentation> The name of the property/attribute to automatically add to entities for versioning purposes. If this value is not specified or it contains only whitespace characters it will be ignored and the property will not be generated. This value can be overridden with the <a href="profile.html#@andromda_hibernate_version">@andromda.hibernate.version</a>tagged value. </documentation> </property> <property name="hibernateAssociationEndOuterJoin"> <default>auto</default> <documentation> Defines the default outer join value for many to one and one to one association ends. Possible values are: <ul> <li>auto</li> <li>true</li> <li>false</li> </ul> For hibernate 3 the above values will be translated to <ul> <li>join</li> <li>select</li> </ul> </documentation> </property> <property name="listTypeImplementation"> <default>java.util.ArrayList</default> <documentation> The implementation type to use for association ends that are modeled as lists. </documentation> </property> <property name="setTypeImplementation"> <default>java.util.HashSet</default> <documentation> The implementation type to use for association ends that are modeled as sets. </documentation> </property> <property name="mapTypeImplementation"> <default>java.util.HashMap</default> <documentation> The implementation type to use for association ends that are modeled as maps. </documentation> </property> <property name="bagTypeImplementation">

169

<default>java.util.ArrayList</default> <documentation> The implementation type to use for association ends that are modeled as bags. </documentation> </property> <property name="specificCollectionInterfaces"> <default>false</default> <documentation> A flag indicating whether or not specific collection interfaces will be used in association end mutators and accessors (i.e. java.util.Set, java.util.List, etc). If this is set to false, then the value of the <a href="#defaultCollectionInterface">defaultCollectionInterface</a> property will used to provide the collection interface. </documentation> </property> <property name="defaultCollectionInterface"> <default>java.util.Collection</default> <documentation> The default collection interface, this is the interface used with association end accessors and mutators if the <a href="#specificCollectionInterfaces">specificCollectionInterfaces</a> flag is set to <code>false</code>. </documentation> </property> <property name="associationEndCollectionIndexName" required="false"> <documentation> The default association end collection index name (this can be overridden by the <a href="profile.html#@andromda_hibernate_collection_index">@andromda.hibernate.collection.index</a>). </documentation> </property> <property name="associationEndCollectionIndexType" required="false"> <default>datatype::String</default> <documentation> The default association end collection index type (this can be overridden by the <a href="profile.html#@andromda_hibernate_collection_index_type">@andromda.hibernate.collection.index.type</a> (this is applicable when the collection is a map). </documentation> </property> <property name="hibernateTypeMappingsUri" required="false"> <documentation> URI specifying the specific mappings from model types to hibernate types. (i.e. <code>file:${basedir}/HibernateTypeMappings.xml</code>). This is not necessary but useful for defining hibernate user types (when hibernate doesn't support a specific type in the manner needed for your application). </documentation> </property> <property name="securityRealm" required="false"> <documentation> The name of the security realm (i.e. animal-quiz, other, etc). <strong>NOTE:</strong>This enables EJB security if specified. </documentation> </property> <property name="customTypesPackage"> <default>org.andromda.persistence.hibernate</default> <documentation> </documentation> </property> <property name="userTypesPackage"> <default>org.andromda.persistence.hibernate.usertypes</default> <documentation> Defines the package for the Hibernate user types </documentation> </property> <property name="serviceLocatorName"> <default>ServiceLocator</default>

170

<documentation> The name to give to the generated service locator class. </documentation> </property> <property name="hibernatePoolSize" required="false"> <documentation> Hibernate connection pool size. </documentation> </property> <property name="hibernateJndiName"> <default>java:/hibernate/SessionFactory</default> <documentation> JNDI name bound to the SessionFactory. </documentation> </property> <property name="xmlEncoding"> <default>UTF-8</default> <documentation> Encoding for generated XML files. </documentation> </property> <property name="generateEntityEqualsAndHashCode"> <default>true</default> <documentation> Indicates whether or not a default equals and hashCode implementation should be generated. </documentation> </property>  <property name="hibernateQueryFactory"> <default>org.hibernate.hql.classic.ClassicQueryTranslatorFactory</default> <documentation> Hibernate3 comes with a brand-new, ANTLR-based HQL/SQL query translator. However, it is still buggy and so in mean time use the Hibernate 2.1 query parser which is still available. Possible values are: <ul> <li>org.hibernate.hql.ast.ASTQueryTranslatorFactory (for the new query parser)</li> <li>org.hibernate.hql.classic.ClassicQueryTranslatorFactory (for the old parser)</li> </ul> </documentation> </property> </propertyGroup> </properties> </namespace>

171

4.Profile.xml <?xml version="1.0" encoding="ISO-8859-1" ?> <profile> <documentation> <p> Dependencies can be used between Services and Entities, they won't need any stereotype assigned to them. These dependencies are used to reference an entity from another entity or service, or to reference a service from an entity or another service. </p> <p> Entity query operations (i.e. finders) can be denoted by setting the query flag on the modeled operation to true (they do not require any stereotypes). </p> <p> Actors represent roles within your model. To designate that a role has access to a given service you must draw a dependency from an Actor to the <a href="Service"><![CDATA[<<Service>>]]></a>. To designate the role has access to to a given operation, you must draw a dependency from an Actor to the operation. </p> <p> <strong>Transitive persistence</strong>in Hibernate is controlled by cascading Hibernate operations. There are four points to adjust that: <ul> <li>the <a href="namespace.html#hibernateDefaultCascade">hibernateDefaultCascade</a>namespace property: the overall default for cascade </li> <li>the <a href="namespace.html#hibernateCompositionCascade">hibernateCompositionCascade</a>namespace property: how an UML composition should be interpreted as cascade </li> <li>the <a href="namespace.html#hibernateAggregationCascade">hibernateAggregationCascade</a>namespace property: how an UML aggregation should be interpreted as cascade </li> <li>the <a href="profile.html#@andromda_hibernate_cascade">@andromda.hibernate.cascade tagged value</a> at the individual association end </li> </ul> The idea is to visualize the cascading hierarchie by using UML composition and aggregation. The inverse direction is marked with cascade="none" to get a clear direction. </p> </documentation> <elements> <elementGroup name="Stereotypes"> <element name="ENTITY"> <documentation> Denotes a class is representing an Hibernate POJO. This will instruct the cartridge to generate an <code>.hbm.xml</code> descriptor and the corresponding class from it. </documentation> <value>Entity</value> <appliedOnElement>class</appliedOnElement> </element>

172

<documentation> Identifica um metafacade(<name>) com o nome do estereótipo(<value>) utilizado na modelagem. Este vínculo permitirá ao AndroMDA associar um estereótipo ao seu metafacade correspondente. </documentation> <element name="ENTITYDW"> <documentation> Denotes a class is representing an Hibernate POJO. This will instruct the cartridge to generate an <code>.hbm.xml</code> descriptor and the corresponding class from it. </documentation> <value>EntityDW</value> <appliedOnElement>class</appliedOnElement> </element> <element name="ENTITYOLTP"> <documentation> Denotes a class is representing an Hibernate POJO. This will instruct the cartridge to generate an <code>.hbm.xml</code> descriptor and the corresponding class from it. </documentation> <value>EntityOLTP</value> <appliedOnElement>class</appliedOnElement> </element> <element name="ENTITYTRANSFORM"> <documentation> Denotes a class is representing an Hibernate POJO. This will instruct the cartridge to generate an <code>.hbm.xml</code> descriptor and the corresponding class from it. </documentation> <value>EntityTransform</value> <appliedOnElement>class</appliedOnElement> </element> <element name="ACTIONDERIVATION"> <documentation> Denotes a class is representing an Hibernate POJO. This will instruct the cartridge to generate an <code>.hbm.xml</code> descriptor and the corresponding class from it. </documentation> <value>ActionDerivation</value> <appliedOnElement>class</appliedOnElement> </element> <element name="ACTIONCONVERSION"> <documentation> Denotes a class is representing an Hibernate POJO. This will instruct the cartridge to generate an <code>.hbm.xml</code> descriptor and the corresponding class from it. </documentation> <value>ActionConversion</value> <appliedOnElement>class</appliedOnElement> </element> <element name="ACTIONCONSTANT"> <documentation> Denotes a class is representing an Hibernate POJO. This will instruct the cartridge to generate an <code>.hbm.xml</code> descriptor and the corresponding class from it. </documentation> <value>ActionConstant</value> <appliedOnElement>class</appliedOnElement> </element> <element name="ACTIONSPLIT"> <documentation> Denotes a class is representing an Hibernate POJO. This will instruct the cartridge to generate an <code>.hbm.xml</code> descriptor and the corresponding class from it. </documentation> <value>ActionSplit</value> <appliedOnElement>class</appliedOnElement> </element>

<element name="SERVICE"> <documentation> Denotes a class is representing an EJB session bean that is supposed to be used as a facade

173

for a set of entities. </documentation> <value>Service</value> <appliedOnElement>class</appliedOnElement> </element> <element name="ENUMERATION"> <documentation> This class will instruct the generation of a type-safe enumeration class. The class implements the required Hibernate interface to be able to be persisted. That way it is possible for Entities to use this enumeration type for their attributes. </documentation> <value>Enumeration</value> <appliedOnElement>class</appliedOnElement> </element> </elementGroup> <elementGroup name="Tagged Values"> <element name="HIBERNATE_QUERY"> <documentation> Defines a hibernate query expression. Note that it's encouraged to model your query body as an OCL constraint (instead of using this tagged value). </documentation> <value>@andromda.hibernate.query</value> <appliedOnElement>An Entity operation marked as a <code>query</code>. </appliedOnElement> </element> <element name="HIBERNATE_USE_NAMED_PARAMETERS"> <documentation> Defines whether the marked finder will use named parameters or not. </documentation> <value>@andromda.hibernate.query.useNamedParameters</value> <appliedOnElement>An Entity operation marked as a <code>query</code>. </appliedOnElement> <allowedValues> <value>true</value> <value>false</value> </allowedValues> </element> <element name="EJB_VIEWTYPE"> <documentation> Defines the view type for a Session EJB. If undefined, the default defined by the <a href="namespace.html#ejbViewType">ejbViewType</a> namespace property will be assumed. </documentation> <value>@andromda.ejb.viewType</value> <appliedOnElement><![CDATA[<<Service>>]]></appliedOnElement> <allowedValues> <value>local</value> <value>remote</value> <value>both</value> </allowedValues> </element> <element name="EJB_TRANSACTION_TYPE"> <documentation> Defines a transaction type for the method. </documentation> <value>@andromda.ejb.transaction.type</value> <appliedOnElement>Service Operation</appliedOnElement> <allowedValues> <value>NotSupported</value> <value>Supports</value> <value>Required</value> <value>RequiresNew</value> <value>Mandatory</value> <value>Never</value> </allowedValues> </element> <element name="HIBERNATE_LAZY"> <documentation> Used to denote how entities, relationships or attributes must be loaded: <code>true</code>for

174

<code>lazy</code>, <code>false</code>for <code>eager</code>. Defaults to <code>false</code>for composite associations (unless <a href="namespace.html#compositionDefinesEagerLoading">compositionDefinesEagerLoading</a>is set to <code>false</code>) and defaults to <code>true</code>for the other kinds. For entities, defaults to <code>false</code> for Hibernate 2 and <code>true</code> for Hibernate 3 and NHibernate. </documentation> <value>@andromda.hibernate.lazy</value> <appliedOnElement> <a href="#Entity"><![CDATA[<<Entity>>]]></a>classes, association ends between <a href="#Entity"><![CDATA[<<Entity>>]]></a>classes, or attributes of an <a href="#Entity"><![CDATA[<<Entity>>]]></a> </appliedOnElement> <allowedValues> <value>true</value> <value>false</value> </allowedValues> </element> <element name="HIBERNATE_INHERITANCE"> <documentation> Used to override the default hibernate inheritance strategy defined by the <a href="namespace.html#hibernateInheritanceStrategy">hibernateInheritanceStrategy</a> namespace property. <ul> Permitted values are: <li>class - table per hierarchy.</li> <li>subclass - table per class in hierarchy.</li> <li>concrete - Table per class.</li> <li>union-subclass - Table per class (only on Hibernate 3).</li> <li> interface - Root class is defined as an interface and the attributes remapped to the subclasses. This is useful in the concrete case because it has limitations in the associations. </li> </ul> <p> The tagged value of @andromda.hibernate.inheritance is set on the base/root class. All subclasses must then follow the same strategy unless interface or concrete is the predecessor strategy. The default strategy is defined by the <a href="namespaces.html#hibernateInheritanceStrategy">hibernateInheritanceStrategy</a> namespace property. </p> </documentation> <value>@andromda.hibernate.inheritance</value> <appliedOnElement><![CDATA[<<Entity>>]]></appliedOnElement> <allowedValues> <value>class</value> <value>subclass</value> <value>concrete</value> <value>union-subclass</value> <value>interface</value> </allowedValues> </element> <element name="HIBERNATE_OUTER_JOIN"> <documentation> Defines if Hibernate will use a outer join for fetching the given assocation end. For Hibernate3 this will result in a fetch clause with values: <ul> <li>join</li> <li>select</li>

175

</ul> </documentation> <value>@andromda.hibernate.outerjoin</value> <appliedOnElement>Association ends between <![CDATA[<<Entity>>]]> classes</appliedOnElement> <allowedValues> <value>auto</value> <value>true</value> <value>false</value> </allowedValues> </element> <element name="HIBERNATE_ENTITY_DYNAMIC_INSERT"> <documentation> Defines if the entity will limit the SQL insert statement to properties with values. This value overrides the <a href="namespace.html#hibernateEntityDynamicInsert">namespace property</a>for this entity. </documentation> <value>@andromda.hibernate.entity.dynamicInsert</value> <appliedOnElement><![CDATA[<<Entity>>]]></appliedOnElement> <allowedValues> <value>true</value> <value>false</value> </allowedValues> </element> <element name="HIBERNATE_ENTITY_DYNAMIC_UPDATE"> <documentation> Defines if the entity will limit the SQL update statements to properties that are modified. This value overrides the <a href="namespace.html#hibernateEntityDynamicUpdate">namespace property</a>for this entity. </documentation> <value>@andromda.hibernate.entity.dynamicUpdate</value> <appliedOnElement></appliedOnElement> <allowedValues> <value>true</value> <value>false</value> </allowedValues> </element> <element name="HIBERNATE_GENERATOR_CLASS"> <documentation> Used to define the generator class used for the hibernate entity. Any of the hibernate generator classes may be used. </documentation> <value>@andromda.hibernate.generator.class</value> <appliedOnElement><![CDATA[<<Entity>>]]></appliedOnElement> <allowedValues> <value>increment</value> <value>identity</value> <value>sequence</value> <value>hilo</value> <value>seqhilo</value> <value>guid</value> <value>uuid</value> <value>uuid.hex</value> <value>uuid.string</value> <value>native</value> <value>assigned</value> <value>select</value> <value>foreign</value> </allowedValues> </element> <element name="HIBERNATE_PROXY"> <documentation> Defines if a proxy will be enabled for the entity. Overrrides the "hibernateProxy" namespace property. </documentation> <value>@andromda.hibernate.entity.proxy</value> <appliedOnElement><![CDATA[<<Entity>>]]></appliedOnElement> <allowedValues> <value>true</value> <value>false</value> </allowedValues> </element>

176

<element name="HIBERNATE_ASSOCIATION_COLLECTION_TYPE"> <documentation> Used to define the mapping for hibernate collections. This value overrides the <a href="namespace.html#hibernateAssociationCollectionType">namespace property</a>. </documentation> <value>@andromda.hibernate.collection.type</value> <appliedOnElement>Association ends between <![CDATA[<<Entity>>]]> classes</appliedOnElement> <allowedValues> <value>set</value> <value>map</value> <value>bag</value> <value>list</value> </allowedValues> </element> <element name="HIBERNATE_ASSOCIATION_SORT_TYPE"> <documentation> Used to define how elements will be sorted within the collection defined by the association. (Only available for maps and sets) This value overrides the <a href="namespace.html#hibernateAssociationSortType">namespace property</a>. </documentation> <value>@andromda.hibernate.sort.type</value> <appliedOnElement>Association ends between <![CDATA[<<Entity>>]]> classes</appliedOnElement> <allowedValues> <value>unsorted</value> <value>natural</value> <value>comparatorClass</value> </allowedValues> </element> <element name="HIBERNATE_ASSOCIATION_ORDER_BY_COLUMNS"> <documentation> Column names that will be used for sorting the collection, with asc or desc optionally. </documentation> <value>@andromda.hibernate.orderByColumns</value> <appliedOnElement>Association ends between <![CDATA[<<Entity>>]]> classes</appliedOnElement> <allowedValues> <value>Properties of this entity</value> </allowedValues> </element> <element name="HIBERNATE_ASSOCIATION_WHERE_CLAUSE"> <documentation> SQL condition to define a subset of available data for the collection </documentation> <value>@andromda.hibernate.whereClause</value> <appliedOnElement>Association ends between <![CDATA[<<Entity>>]]> classes</appliedOnElement> <allowedValues> <value>An SQL code fragment</value> </allowedValues> </element> <element name="HIBERNATE_ASSOCIATION_INDEX"> <documentation> Column containing the collection index, overrides the <a href="namespace.html#associationEndCollectionIndexName">associationEndCollectionIndexName</a> </documentation> <value>@andromda.hibernate.collection.index</value> <appliedOnElement>Association ends between <![CDATA[<<Entity>>]]> classes</appliedOnElement> <allowedValues> <value>A property of this entity</value> </allowedValues> </element> <element name="HIBERNATE_ASSOCIATION_INDEX_TYPE"> <documentation> The type of the column containing the collection index, overrides the

177

<a href="namespace.html#associationEndCollectionIndexType">associationEndCollectionIndexType</a> </documentation> <value>@andromda.hibernate.collection.index.type</value> <appliedOnElement>Association ends between <![CDATA[<<Entity>>]]> classes</appliedOnElement> <allowedValues> <value>A property of this entity</value> </allowedValues> </element> <element name="HIBERNATE_VERSION_PROPERTY"> <documentation> Specifies wheter or not the entity will have a version property. If a value is present, then the entity will have a version property with the name specified within the tagged value. </documentation> <value>@andromda.hibernate.version</value> <appliedOnElement><![CDATA[<<Entity>>]]></appliedOnElement> <allowedValues> <value>The name of the version property</value> </allowedValues> </element> <element name="HIBERNATE_CASCADE"> <documentation> Place an individual cascade value at an association end, overriding the properties <a href="namespace.html#hibernateDefaultCascade">hibernateDefaultCascade</a>, <a href="namespace.html#hibernateCompositionCascade">hibernateCompositionCascade</a>and <a href="namespace.html#hibernateAggregationCascade">hibernateAggregationCascade</a>. </documentation> <value>@andromda.hibernate.cascade</value> <appliedOnElement>Association ends between <![CDATA[<<Entity>>]]> classes</appliedOnElement> </element> <element name="HIBERNATE_FORMULA"> <documentation> Defines an attribute of a class as a calculated value. This tagged value stores the SQL formula that will be used to assign a value to this property. </documentation> <value>@andromda.hibernate.formula</value> <appliedOnElement>The attribute of an <![CDATA[<<Entity>>]]></appliedOnElement> <allowedValues> <value>An SQL code fragment</value> </allowedValues> </element> <element name="ENTITY_DISCRIMINATOR_COLUMN"> <documentation> Used at the class level of an entity and is optional. This value indicates the name of the column to be used for the discriminator. If not specified for the SINGLE_TABLE or JOINED inheritance mapping strategies, then default to <b>TYPE</b>. </documentation> <value>@andromda.persistence.discriminator.column.name</value> <appliedOnElement>The <![CDATA[<<Entity>>]]> classes</appliedOnElement> <allowedValues> <value>column name</value> </allowedValues> </element> <element name="ENTITY_DISCRIMINATOR_TYPE"> <documentation> Used to override the default entity inheritance discriminator type defined by the <a href="namespace.html#entityDiscriminatorType"> entityDiscriminatorType </a> namespace property. <ul> Permitted values are:

178

<li>STRING</li> <li>CHAR</li> <li>INTEGER</li> </ul> <p> The tagged value of @andromda.persistence.discriminator.type is set once on the base/root class to indicate the type of the column used for the discriminator. The default discriminator type is defined by the <a href="namespaces.html#entityDiscriminatorType"> entityDiscriminatorType </a> namespace property. </p> </documentation> <value>@andromda.persistence.discriminator.type</value> <appliedOnElement>The <![CDATA[<<Entity>>]]> classes</appliedOnElement> <allowedValues> <value>STRING</value> <value>CHAR</value> <value>INTEGER</value> </allowedValues> </element> <element name="ENTITY_DISCRIMINATOR_VALUE"> <documentation> Used at the class level of an entity and is optional. This is the value that indicates that the row is an entity of the annotated entity type. It should be specified for each class in the hierarchy. </documentation> <value>@andromda.persistence.discriminator.value</value> <appliedOnElement>The <![CDATA[<<Entity>>]]> classes</appliedOnElement> <allowedValues> <value>A String</value> </allowedValues> </element> <element name="HIBERNATE_PROPERTY_INSERT"> <documentation> Specifies whether a mapped column should be included in SQL INSERT statements. Setting to <code>false</code> allows the column to be initialized using other mechanisms such as a value defaulted by the database. Defaults to <code>true</code>. </documentation> <value>@andromda.hibernate.property.insert</value> <appliedOnElement>the attribute of an <![CDATA[<<Entity>>]]></appliedOnElement> <allowedValues> <value>true</value> <value>false</value> </allowedValues> </element> <element name="HIBERNATE_PROPERTY_UPDATE"> <documentation> Specifies whether a mapped column should be included in SQL UPDATE statements. Setting to <code>false</code> allows the column to be updated using other mechanisms such as a value defaulted by the database. Defaults to <code>true</code>. </documentation> <value>@andromda.hibernate.property.update</value> <appliedOnElement>the attribute of an <![CDATA[<<Entity>>]]></appliedOnElement> <allowedValues> <value>true</value> <value>false</value> </allowedValues> </element> <element name="HIBERNATE_XML_TAG_NAME"> <documentation> Defines the name of the XML element that is generated when an entity, attribute, or associated entity is represented in XML format. Valid only when XML persistence has been enabled. Controls the <i>node</i> attribute in the Hibernate mapping file.

179

See also <a href="namespace.html#hibernateXMLPersistence">hibernateXMLPersistence</a> </documentation> <value>@andromda.hibernate.xml.tagName</value> <appliedOnElement>the attribute of an <![CDATA[<<Entity>>]]>, or an the <![CDATA[<<Entity>>]]> itself, or on an association end between <![CDATA[<<Entity>>]]> classes</appliedOnElement> <allowedValues> <value>Any valid XML tag name</value> </allowedValues> </element> <element name="HIBERNATE_XML_EMBED"> <documentation> Specifies wheter or not the entity attached to the association end should be embedded as a complete XML structure, or simply as a referenc to its ID. Controls the <i>embed-xml</i> attribute in the Hibernate mapping file. See also <a href="namespace.html#hibernateXMLPersistence">hibernateXMLPersistence</a> </documentation> <value>@andromda.hibernate.xml.embed</value> <appliedOnElement>Association ends between <![CDATA[<<Entity>>]]> classes</appliedOnElement> <allowedValues> <value>true</value> <value>false</value> </allowedValues> </element> </elementGroup> <elementGroup name="Tagged Values for caching"> <documentation> The following are tagged values exclusively used for tuning the persistence cache. </documentation> <element name="HIBERNATE_USE_QUERY_CACHE"> <documentation> Defines is caching is enabled for this query </documentation> <value>@andromda.hibernate.query.useCache</value> <appliedOnElement>A query operation</appliedOnElement> <allowedValues> <value>true</value> <value>false</value> </allowedValues> </element> <element name="HIBERNATE_ENTITY_CACHE"> <documentation> Defines the cache strategy for the Entity. </documentation> <value>@andromda.hibernate.entity.cache</value> <appliedOnElement><![CDATA[<<Entity>>]]></appliedOnElement> <allowedValues> <value>read-write</value> <value>nonstrict-read-write</value> <value>read-only</value> </allowedValues> </element> <element name="HIBERNATE_ENTITYCACHE_DISTRIBUTED"> <documentation> Defines whether the cache for this entity is to be distributed. </documentation> <value>@andromda.hibernate.entity.cache.distributed</value> <appliedOnElement><![CDATA[<<Entity>>]]></appliedOnElement> <allowedValues> <value>true</value> <value>false</value> </allowedValues> </element> <element name="HIBERNATE_ASSOCIATION_CACHE"> <documentation> Defines the cache strategy for the association. </documentation> <value>@andromda.hibernate.association.cache</value> <appliedOnElement>Association between <![CDATA[<<Entity>>]]> classes</appliedOnElement> <allowedValues>

180

<value>read-write</value> <value>nonstrict-read-write</value> <value>read-only</value> </allowedValues> </element> <element name="HIBERNATE_ASSOCIATIONCACHE_DISTRIBUTED"> <documentation> Defines whether the cache for this association is to be distributed. </documentation> <value>@andromda.hibernate.association.cache.distributed</value> <appliedOnElement><![CDATA[<<Entity>>]]></appliedOnElement> <allowedValues> <value>true</value> <value>false</value> </allowedValues> </element> <element name="HIBERNATE_EHCACHE_MAX_ELEMENTS"> <documentation> EhCache property. Defines the maximum number of objects that will be created in memory. </documentation> <value>@andromda.hibernate.ehcache.maxElementsInMemory</value> <appliedOnElement><![CDATA[<<Entity>>]]></appliedOnElement> <allowedValues> <value>A strictly positive integer</value> </allowedValues> </element> <element name="HIBERNATE_EHCACHE_ETERNAL"> <documentation> EhCache property. Defines if elements are eternal. </documentation> <value>@andromda.hibernate.ehcache.eternal</value> <appliedOnElement><![CDATA[<<Entity>>]]></appliedOnElement> <allowedValues> <value>true</value> <value>false</value> </allowedValues> </element> <element name="HIBERNATE_EHCACHE_TIME_TO_IDLE"> <documentation> EhCache property. Defines the time to idle for an element before it expires. </documentation> <value>@andromda.hibernate.ehcache.timeToIdleSeconds</value> <appliedOnElement><![CDATA[<<Entity>>]]></appliedOnElement> <allowedValues> <value>A strictly positive integer</value> </allowedValues> </element> <element name="HIBERNATE_EHCACHE_TIME_TO_LIVE"> <documentation> EhCache property. Defines the time to live for an element before it expires. </documentation> <value>@andromda.hibernate.ehcache.timeToLiveSeconds</value> <appliedOnElement><![CDATA[<<Entity>>]]></appliedOnElement> <allowedValues> <value>A strictly positive integer</value> </allowedValues> </element> <element name="HIBERNATE_EHCACHE_OVERFLOW_TO_DISK"> <documentation> EhCache property. Defines if elements can overflow to disk. </documentation> <value>@andromda.hibernate.ehcache.overflowToDisk</value> <appliedOnElement><![CDATA[<<Entity>>]]></appliedOnElement> <allowedValues> <value>true</value> <value>false</value> </allowedValues> </element> </elementGroup> </elements> </profile>

universidade federal do rio de janeiro aumentando o...

Documents