Analise e Integrac¸´ ao de Infraestruturas para...

UNIVERSIDADE DE LISBOA

FACULDADE DE CIENCIAS

DEPARTAMENTO DE INFORMATICA

Analise e Integracao de Infraestruturas para Centro de Dados

Ivo Miguel Ferreira da Silva

Mestrado em Engenharia InformaticaEspecializacao em Arquitetura, Sistemas e Redes de Computadores

Dissertacao orientada por:Prof. Doutor Carlos Jorge da Conceicao Teixeira

Ana Cristina Branco Guimaraes Maia

2018

Agradecimentos

Agradeco ao orientador da faculdade, a co-orientadora da empresa e a equipa que ini-ciou este projeto todo o auxılio prestado durante o seu desenvolvimento.

i

Dedico este trabalho ao Departamento de Informatica da FCUL.

Resumo

O projeto de Analise e Integracao de Infraestruturas para Centro de Dados consistena reuniao e uniformizacao de dados recolhidos de bases de dados de diversos provedo-res. A variedade de bases de dados deve-se a diversidade de sistemas em producao quesuportam os servicos prestados por uma multinacional de telecomunicacoes. Este projetoresulta da procura por uma solucao inovadora que possa servir os novos servicos na areadas telecomunicacoes nos proximos anos e permita substituir os sistemas atuais que estaolimitados a cada tecnologia de base de dados. Os dados reunidos por este sistema sao pu-blicados num intermediario Apache Kafka e persistidos com recurso a tecnologia ApacheHadoop para aumentar a disponibilidade dos dados e possibilitar a realizacao de analisesposteriores. Este relatorio descreve a Analise, o Desenho, o Desenvolvimento e os Testesaos conectores para bases de dados SQL Server e MySQL que se baseiam num conectorOracle previamente desenvolvido para funcionar com o sistema descrito acima. Com otrabalho descrito neste documento, o sistema realiza o seu proposito com bases de dadosOracle, SQL Server e MySQL ficando preparado para funcionar tambem com outros co-nectores de bases de dados caso se considere necessario. Este sistema esta preparado parapermitir a futura introducao de sistemas inovadores de analise posterior de dados.

Palavras-chave: Captura de dados estruturados, Conversao de dados, Integracao dedados, Envio de dados, Bases de Dados.

iii

Abstract

The project Analysis and Integration of Infrastructures for Datacenter is the reunionand standardization of databases data from different companies. The diversity of databasescomes from the kind of prodution systems that backing the telecomunications multina-tional services. This project remains from the search for new solutions to furnish futureservices developed in the next years in telecomunications area and to replace the runningsystems that are limited to each database company. The data gathered by this systemis published in an intermediary message broker called Apache Kafka and is persisted inApache Hadoop modules and related projects to increase the data availability and allowposterior analysis. This report describes the analysis, design, development and tests todatabase conectors for SQL Server and MySQL. These conectors grounds on previousdeveloped Oracle conector to work with the above described system. Using the work de-scribed in this document, the system fulfils your objective and remains adaptable to workwith other database conectors in addition to Oracle, SQL Server and MySQL databases,if necessary. This system is already prepared to make data available to new data miningsystems.

Keywords: Change Data Capture, Data Conversion and Standardization, DataIntegration, Data transmission, Databases.

iv

Conteudo

Lista de Figuras ix

Lista de Tabelas xii

Glossario xiii

1 Introducao 11.1 Enquadramento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Motivacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2.1 Da empresa de telecomunicacoes . . . . . . . . . . . . . . . . . 21.2.2 Da consultora . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2.3 Da equipa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2.4 Individuais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3 Objectivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3.1 Da empresa de telecomunicacoes . . . . . . . . . . . . . . . . . 31.3.2 Da consultora . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.3.3 Da equipa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.3.4 Individuais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.4 Contribuicoes do autor . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.5 Estrutura do documento . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2 Estado da arte 112.1 Conector SQL Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.1.1 Funcionalidades incluıdas . . . . . . . . . . . . . . . . . . . . . 112.1.2 Versoes empresariais . . . . . . . . . . . . . . . . . . . . . . . . 112.1.3 Versoes empresariais de codigo aberto . . . . . . . . . . . . . . . 122.1.4 Versoes particulares de codigo aberto . . . . . . . . . . . . . . . 12

2.2 Conector MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.2.1 Funcionalidades incluıdas . . . . . . . . . . . . . . . . . . . . . 142.2.2 Versoes empresariais . . . . . . . . . . . . . . . . . . . . . . . . 152.2.3 Versoes empresariais de codigo aberto . . . . . . . . . . . . . . . 152.2.4 Versoes particulares de codigo aberto . . . . . . . . . . . . . . . 15

v

2.3 Discussao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3 Analise 193.1 Descricao do projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.2 Requisitos detalhados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.2.1 Requisitos funcionais . . . . . . . . . . . . . . . . . . . . . . . . 203.2.2 Requisitos nao funcionais . . . . . . . . . . . . . . . . . . . . . 213.2.3 Requisitos inversos . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.3 Casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.4 Diagramas de fluxos de dados . . . . . . . . . . . . . . . . . . . . . . . 283.5 Diagrama de transicao de estados dos conectores . . . . . . . . . . . . . 313.6 Diagramas de atividades . . . . . . . . . . . . . . . . . . . . . . . . . . 313.7 Diagramas de sequencia . . . . . . . . . . . . . . . . . . . . . . . . . . 353.8 Diagramas de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4 Planeamento 434.1 Recursos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.1.1 Recursos humanos . . . . . . . . . . . . . . . . . . . . . . . . . 434.1.2 Tecnologias envolvidas . . . . . . . . . . . . . . . . . . . . . . . 44

4.2 Estimacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.2.1 Do esforco disponıvel . . . . . . . . . . . . . . . . . . . . . . . 454.2.2 Modelos empıricos (COCOMO) . . . . . . . . . . . . . . . . . . 454.2.3 Dados historicos . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.3 Processo de desenvolvimento de software . . . . . . . . . . . . . . . . . 474.4 Planeamento detalhado do projeto . . . . . . . . . . . . . . . . . . . . . 47

4.4.1 Decomposicao das tarefas . . . . . . . . . . . . . . . . . . . . . 474.4.2 Afetacao das tarefas . . . . . . . . . . . . . . . . . . . . . . . . 474.4.3 Diagrama Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . 484.4.4 Diagrama da alocacao de recursos . . . . . . . . . . . . . . . . . 48

4.5 Analise crıtica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484.5.1 Viabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484.5.2 Solucoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5 Implementacao 515.1 Especificacao de procedimentos . . . . . . . . . . . . . . . . . . . . . . 515.2 Organizacao do conector . . . . . . . . . . . . . . . . . . . . . . . . . . 52

5.2.1 Conector Oracle . . . . . . . . . . . . . . . . . . . . . . . . . . 525.2.2 Conector SQL Server . . . . . . . . . . . . . . . . . . . . . . . . 525.2.3 Conector MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.3 Funcionalidades do sistema . . . . . . . . . . . . . . . . . . . . . . . . . 53

vi

5.4 Aspetos significativos da implementacao . . . . . . . . . . . . . . . . . . 55

6 Testes 576.1 Plano de testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

6.1.1 Extensao dos testes unitarios . . . . . . . . . . . . . . . . . . . . 576.1.2 Testes unitarios ao conector SQL Server . . . . . . . . . . . . . . 576.1.3 Testes unitarios ao conector MySQL . . . . . . . . . . . . . . . . 606.1.4 Extensao dos testes de integracao . . . . . . . . . . . . . . . . . 616.1.5 Testes de integracao . . . . . . . . . . . . . . . . . . . . . . . . 62

6.2 Conclusoes dos testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 626.2.1 Cobertura total . . . . . . . . . . . . . . . . . . . . . . . . . . . 626.2.2 Erros detetados no conector SQL Server . . . . . . . . . . . . . . 626.2.3 Erros detetados no conector MySQL . . . . . . . . . . . . . . . . 64

6.3 Discussao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

7 Conclusoes 677.1 Decomposicao, atribuicao e calendarizacao das tarefas realizadas . . . . . 67

7.1.1 Medidas do projeto . . . . . . . . . . . . . . . . . . . . . . . . . 677.2 Planeado vs. executado . . . . . . . . . . . . . . . . . . . . . . . . . . . 687.3 Avaliacao post-mortem . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

7.3.1 Analise global do esforco despendido . . . . . . . . . . . . . . . 687.3.2 Analise global do decurso do projeto . . . . . . . . . . . . . . . . 69

7.4 Sıntese crıtica do projeto . . . . . . . . . . . . . . . . . . . . . . . . . . 697.5 Conclusao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

8 Futuros desenvolvimentos 73

Bibliografia 84

9 Apendices 85.1 Plano de Testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

.1.1 Testes unitarios ao conector SQL Server . . . . . . . . . . . . . . 86

.1.2 Testes unitarios ao conector MySQL . . . . . . . . . . . . . . . . 142

.1.3 Testes de integracao . . . . . . . . . . . . . . . . . . . . . . . . 168.2 Exemplos de tabelas de producao . . . . . . . . . . . . . . . . . . . . . . 174.3 Diagrama Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

vii

Lista de Figuras

3.1 Diagrama de Fluxos de Dados do Sistema nıvel 0 . . . . . . . . . . . . . 283.2 Diagrama de Fluxos de Dados do Sistema nıvel 1 . . . . . . . . . . . . . 293.3 Diagrama de Fluxos de Dados da BD Oracle nıvel 2 . . . . . . . . . . . . 303.4 Diagrama de Fluxos de Dados da BD SQL Server nıvel 2 . . . . . . . . . 323.5 Diagrama de Fluxos de Dados da BD MySQL nıvel 2 . . . . . . . . . . . 333.6 Diagrama de Transicao de Estados dos Conectores . . . . . . . . . . . . 343.7 Diagrama de Atividades Geral do Sistema . . . . . . . . . . . . . . . . . 363.8 Diagrama de Atividades do Conector Oracle . . . . . . . . . . . . . . . . 373.9 Diagrama de Atividades do Conector SQL Server . . . . . . . . . . . . . 383.10 Diagrama de Atividades do Conector MySQL . . . . . . . . . . . . . . . 393.11 Diagrama de Sequencia do Conector Oracle . . . . . . . . . . . . . . . . 403.12 Diagrama de Sequencia do Conector SQL Server . . . . . . . . . . . . . 403.13 Diagrama de Sequencia do Conector MySQL . . . . . . . . . . . . . . . 413.14 Diagrama de Classes do Conector Oracle . . . . . . . . . . . . . . . . . 413.15 Diagrama de Classes do Conector SQL Server . . . . . . . . . . . . . . . 423.16 Diagrama de Classes do Conector MySQL . . . . . . . . . . . . . . . . . 42

4.1 Diagrama da Alocacao de Recursos . . . . . . . . . . . . . . . . . . . . 49

6.1 Exemplo de Codigo de Teste do conector SQL Server . . . . . . . . . . . 59

1 Tabela de producao com poucas colunas . . . . . . . . . . . . . . . . . . 1742 Tabela de producao com muitas colunas . . . . . . . . . . . . . . . . . . 1753 Diagrama Gantt parte 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 1764 Diagrama Gantt parte 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 1775 Legenda do diagrama Gantt . . . . . . . . . . . . . . . . . . . . . . . . . 178

ix

Lista de Tabelas

2.1 Comparacao entre os trabalhos relacionados com o conector SQLServer . 132.2 Comparacao entre as funcionalidades existentes no SQLServer . . . . . . 142.3 Comparacao entre os trabalhos relacionados com o conector MySQL . . . 172.4 Comparacao entre as funcionalidades existentes no MySQL . . . . . . . . 18

4.1 Competencias previas nas linguagens utilizadas . . . . . . . . . . . . . . 454.2 Estimacao por decomposicao de linhas de codigo . . . . . . . . . . . . . 46

5.1 Conversao entre os tipos das colunas [11] . . . . . . . . . . . . . . . . . 535.2 Conversao para JSON suportar caracteres especiais . . . . . . . . . . . . 54

6.1 Relacao entre os tipos das operacoes e os dados registados . . . . . . . . 61

1 Plano de testes de caixa preta ao procedimento usp AnalyseStrings . . . . 862 Resultados dos testes de caixa preta ao procedimento usp AnalyseStrings 863 Plano de testes de caixa preta ao procedimento usp ConvertJSONType . . 914 Plano de testes de caixa preta ao procedimento usp DescribeTable . . . . 965 Resultados dos testes de caixa preta ao procedimento usp DescribeTable . 976 Plano de testes de caixa preta ao procedimento usp FetchTableAlterations 1047 Resultados dos testes de caixa preta ao proc usp FetchTableAlterations . . 1058 Plano de testes de caixa preta ao procedimento usp GetCustomResults . . 1119 Resultados dos testes de caixa preta ao procedimento usp GetCustomRe-

sults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11110 Plano de testes de caixa preta ao procedimento usp GetLastRows . . . . . 11411 Plano de testes de caixa preta ao procedimento usp GetTableColsList . . 11812 Resultados dos testes de caixa preta ao procedimento usp GetTableColsList11813 Plano de testes de caixa preta ao procedimento usp MakeJSON . . . . . . 12114 Resultados dos testes de caixa preta ao procedimento usp MakeJSON . . 12215 Plano de testes de caixa preta ao procedimento usp RegisterTableInCDC . 12816 Plano de testes de caixa preta ao proc usp SendJSONByHTTPWithSQL-

CLR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13017 Plano de testes de caixa preta ao procedimento usp SyncCDCTable . . . . 13618 Plano de testes de caixa preta ao procedimento usp UnregisterTableInCDC 139

xi

19 Plano de testes de caixa preta a funcao readConfigFile . . . . . . . . . . . 14220 Resultados dos testes de caixa preta a funcao readConfigFile . . . . . . . 14321 Plano de testes de caixa preta a funcao getLastClosedProcLogFile . . . . 14522 Resultados dos testes de caixa preta a funcao getLastClosedProcLogFile . 14523 Plano de testes de caixa preta a funcao readLastClosedLogFile . . . . . . 14824 Resultados dos testes de caixa preta a funcao readLastClosedLogFile . . . 14925 Plano de testes de caixa preta a funcao updateLogPosition . . . . . . . . 15326 Plano de testes de caixa preta a funcao getTimestamp . . . . . . . . . . . 15727 Plano de testes de caixa preta a funcao searchForAlterationsInOpenLogFile16028 Plano de testes de caixa preta ao procedimento registerTableInCDC . . . 163

xii

Glossario

BD base de dados. 1–9, 11, 13, 14, 16–22, 28, 29, 31, 35, 43, 44, 51, 53, 56, 57, 63, 64,66, 71–73, 75, 107–110, 114, 115, 142, 143, 147–153, 155–170, 173–176

CDC recolha de alteracoes - change data capture. 5, 8, 11, 12, 15, 19, 31, 35, 52, 55, 65,131, 135, 136, 140, 142, 143

COCOMO Constructive Cost MOdel. 45, 69

consumidor JSON interface Kafka-REST-Proxy. 20, 44

cURL ferramenta para transferencia de dados. 52, 57

Ethernet ligacao fısica a rede. 21

Gantt diagrama das tarefas do projeto. 9, 10, 44, 48, 69

gatilho trigger. 2, 11, 16

GTID identificador unico. 16

Hadoop estrutura (framework) de processamento distribuıdo. 44

HDFS sistema de ficheiros Hadoop - Hadoop File System. 44

HIVE armazem de dados. 6, 44

HTTP protocolo de transferencia de dados - hypertext transfer protocol. 14, 16, 21, 44

HUE interface Web de analise de dados. 44

intermediario Kafka intermediario Apache para publicacao de alteracoes. 6–9, 12, 15,20–22, 28, 29, 31, 35, 44, 57, 64, 67, 75, 173–176

JDBC ligacao a base de dados usando java - java database connection. 12

xiii

xiv

JSON javascript object notation. 6, 7, 11, 16, 17, 20–22, 29, 31, 35, 44, 51–53, 55–57,62, 63, 72, 91, 95–97, 103–105, 110, 111, 115, 128, 129, 135, 136, 149, 151–154,161, 173–176

NoSQL base de dados nao relacional. 71, 75

Oozie escalonador de tarefas. 44

prospecao de dados Data Mining. 72, 75

RACC Cobertura Restrita da Clausula Ativa - Restricted Active Clause Coverage. 64,89, 93, 98, 116, 120, 123, 130, 132, 138, 141, 144, 147, 150, 155, 159, 162, 165

SGBD sistema de gestao da base de dados. 2, 5–8, 11, 14, 18, 20, 21, 31, 35, 52, 53, 56,67, 90

SQL linguagem de consulta estruturada - structured query language. 21, 45, 64, 65,95–97, 105, 110, 111, 115, 120–122

SQLCLR SQL common language runtime. 51

SQLCMD acesso SQL a linha de comandos. 52

YARN gestor de recursos. 44

ZooKeeper servico de informacoes de configuracao. 44

Capıtulo 1

Introducao

1.1 Enquadramento

Este projeto esta incluıdo num plano de desenvolvimento e atualizacao dos sistemasinternos de uma empresa de telecomunicacoes europeia. Esta multinacional tem maisde um milhao de clientes particulares e algumas centenas de clientes empresariais. Nosseus projetos tem atualmente mais de dez mil trabalhadores diretos e alguns milhares deparceiros em projetos complementares.

Os projetos de inovacao e investigacao de novas solucoes para os sistemas internos daempresa de telecomunicacoes estao entregues a alguns parceiros que lhe adjudicam maisde duas centenas de trabalhadores a tempo inteiro. Este projeto esta sob a alcada de umaconsultora multinacional, com duas centenas de clientes distribuıdos por cem paıses ondeemprega mais de meio milhar de profissionais da area das tecnologias.

Nestes projetos tambem estao colocados alguns trabalhadores de uma empresa nacio-nal com algumas dezenas de trabalhadores, a AKTM, a qual pertence a coorientadora daempresa que esta a acompanhar este projeto.

Este projeto ficou sob a responsabilidade de uma equipa de dois trabalhadores daconsultora multinacional para analisarem, desenharem, desenvolverem e testarem umasolucao que capture, integre e disponibilize os dados das diversas tecnologias de bases dedados.

O autor foi integrado na equipa que iniciou este projeto para continuar o trabalho japrincipiado seguidamente descrito.

1.2 Motivacao

Seguidamente descreverei a motivacao das varias entidades e intervenientes.

1

Capıtulo 1. Introducao 2

1.2.1 Da empresa de telecomunicacoes

• Melhorar a gestao dos recursos da organizacao de modo a obter informacoes maiscompletas e detalhadas sobre o funcionamento das base de dados (BD) em producao.

• Complementar e melhorar a oferta de servicos aos clientes colocando em producaonovos sistemas para transmitir fluxos de dados quase em tempo real.

• Descobrir novas oportunidades de negocio utilizando resultados de uma analise pro-funda a grandes conjuntos de dados obtidos dos sistemas em producao.

1.2.2 Da consultora

• Extrair conclusoes uteis da analise dos dados obtidos dos sistemas em producao quedemonstrem as potencialidades deste projeto.

• Suportar subscritores com uma vasta diversidade de interesses na obtencao de da-dos, em termos de:

– frequencia: minuto a minuto, horaria ou diaria.

– atraso: 5 a 10 minutos, 1 hora ou 24 horas.

– tipo: caracteres e numeros, imagens ou vıdeo.

– quantidade de dados: dezenas de Kb, Mb ou Gb.

– largura de banda: dezenas de Mb/s ate 1Gb/s.

– multiplicidade dos produtores: 1 produtor ou poucas dezenas.

– diversidade de origens: BD Oracle, SQLServer ou MySQL.

• Aumentar o nıvel de tolerancia a faltas dos dados persistidos.

1.2.3 Da equipa

• Manter todos os sistemas em producao da empresa de telecomunicacoes a funcionarsem constrangimentos apesar de serem:

– alteradas as configuracoes pre-definidas do sistema de gestao da base de dados(SGBD).

– ativados e utilizados servicos complementares do SGBD.

– criados e executados novos procedimentos e funcoes.

• Evitar incompatibilidades e atrasos introduzidos por modulos externos as BD:

– minimizando a utilizacao de triggers (gatilhos) [12].


– utilizando procedimentos e funcoes assıncronas.

– otimizando as pesquisas realizadas as BD de producao.

• Suportar a obtencao quase em tempo real de fluxos de dados dos sistemas emproducao para:

– viabilizar novos servicos que necessitem de fluxos de texto, imagens e vıdeos.

– permitir analisar a operacao dos sistemas prestadores de servicos para identi-ficar problemas nos primeiros minutos apos a sua ocorrencia.

1.2.4 Individuais

• Trabalhar em equipa num projeto real.

• Ter contacto com ambientes empresariais.

• Contribuir para uma solucao da empresa de telecomunicacoes.

• Aplicar os conhecimentos obtidos durante a formacao academica.

• Adquirir experiencia de programacao em PL/SQL e T-SQL.

• Compreender o funcionamento interno das varias tecnologias de BD.

• Escolher a forma mais adequada para registar e exportar as alteracoes das BD emproducao.

• Resolver o desafio da integracao de dados num sistema com varios provedores deBD.

1.3 Objectivos

Seguidamente descreverei os objetivos das varias entidades e intervenientes.

1.3.1 Da empresa de telecomunicacoes

• Substituir o sistema antigo por um mais atual que satisfaca os requisitos dos novosservicos prestados aos clientes.

• Definir um novo padrao de integracao de dados moderno e dinamico que possasubstituir o padrao utilizado atualmente nos sistemas em producao.

• Alterar paradigma de obtencao de dados da empresa para publicador/subscritor [33]porque este modelo diminui as dependencias entre os sistemas e e mais adequado autilizacao de dados pretendida.


• Realizar uma analise profunda dos dados produzidos pelos sistemas em producaoque possibilite conhecer todas as potencialidades dos sistemas e otimiza-los.

• Armazenar todos os dados obtidos de sistemas em producao por tempo indetermi-nado mantendo-os acessıveis para analises posteriores.

• Definir um mecanismo de captura e integracao de dados que suporte a transmissaode fluxos de dados (streaming) e se adeque a prestacao de servicos da proximageracao.

1.3.2 Da consultora

• Atualizar o paradigma de distribuicao de dados:

– de recolha apenas dos dados subscritos para o paradigma Publish/Subscribecomecar a recolher, integrar e armazenar todos os dados produzidos.

– para diminuir a dependencia entre os produtores e os consumidores.

– para aumentar a quantidade de informacao armazenada de modo a possibilitaruma analise posterior dos dados que nao sao utilizados atualmente.

– para suportar a integracao com todos os sistemas produtores de dados da em-presa.

• Integrar quase em tempo real dados de sistemas muito distintos como os produtores:

– que utilizam provedores de BD distintos.

– de dezenas de Kb de dados por segundo ate dezenas de Gb por segundo.

– de dados crıticos para a prestacao de servicos aos clientes ou os produtores deregistos de operacoes que apenas interessam a equipa de desenvolvimento.

• Persistir os dados recolhidos num repositorio Hadoop.

• Distribuir os dados corretamente em funcao das necessidades do recetor que podemvariar:

– na frequencia: desde muito reduzida ate muito elevada.

– no atraso: curto ou prolongado.

– no tipo: dados textuais de operacao ou multimedia.

– na quantidade de dados: cabecalhos, metadata ou conteudos para clientes.

– na largura de banda: ADSL, fibra otica ou bastidor.

– na multiplicidade de produtores: apenas uma amostra como exemplo ate todosos que pertencem ao sistema.


– na diversidade de origens: apenas de um ate todos os provedores de BD.

• Aplicar analise de grandes conjuntos de dados sobre os dados persistidos dos siste-mas em producao para:

– aumentar o conhecimento sobre os dados que a empresa de telecomunicacoestem ao seu dispor.

– melhorar o acesso aos dados persistidos.

– identificar e catalogar as informacoes importantes.

– auxiliar a empresa de telecomunicacoes na tomada de decisoes como:

∗ onde devem ser realizados os proximos investimentos.

∗ que servicos trazem maiores lucros e prejuızos.

1.3.3 Da equipa

• Definir um novo mecanismo de captura de alteracoes que suporte os requisitos dosfuturos sistemas da empresa nomeadamente:

– uma maior quantidade de dados.

– a emissao de fluxos de dados com maior frequencia.

– a obtencao dos dados com atrasos mais reduzidos.

– uma maior largura de banda.

• Disponibilizar uma interface para envio e rececao de fluxos de dados dos sistemasem producao para o armazenamento persistente.

• Melhorar a eficiencia da captura de alteracoes das BD em operacao:

– obtendo alteracoes das BD em producao de forma estavel e retrocompatıvel.

– utilizando aplicacoes de captura de dados.

1.3.4 Individuais

• Analisar as diversas abordagens para capturar dados numa BD em producao, como:

– as ferramentas de recolha de alteracoes - change data capture (CDC) forneci-das pelos SGBD.

– os mecanismos de replicacao.

– o acesso aos registos de operacoes.

– a utilizacao de ferramentas externas como as referidas no estado da arte.


• Analisar as diversas alternativas para extrair alteracoes das BD em producao, como:

– a utilizacao de bibliotecas C#.

– a execucao de uma aplicacao do sistema operativo pela linha de comandos.

– a replicacao da BD em producao para comparar o seu conteudo anterior eposterior a uma alteracao e registar as alteracoes efetuadas.

– a utilizacao de um programa externo em C.

• Identificar os desafios do desenvolvimento, como:

– a periodicidade da obtencao das alteracoes.

– capturar alteracoes apenas das tabelas indicadas.

– registar apenas as operacoes que produzem alteracoes nas tabelas.

– o agrupamento das linhas alteradas em cada tabela.

– a formatacao do javascript object notation (JSON) [45] das alteracoes captu-radas.

– a extracao das alteracoes do SGBD.

– o envio para o intermediario Apache para publicacao de alteracoes (inter-mediario Kafka) escolhido previamente pela equipa para reunir, persistir noarmazem de dados (HIVE) e distribuir todas as alteracoes independentementeda sua tecnologia de origem.

– a eliminacao das alteracoes publicadas com sucesso.

• Planear a arquitetura da implementacao para cada tecnologia de base de dados como objetivo de:

– registar as alteracoes.

– formatar o JSON.

– enviar o JSON.

– limpar as alteracoes ja enviadas.

• Especificar os contratos dos procedimentos e funcoes.

• Implementar os procedimentos e funcoes seguindo boas praticas de programacao.

• Redigir o plano de testes unitarios e de integracao para garantir uma cobertura detodas as linhas de codigo.

• Executar o plano de testes seguindo os procedimentos recomendados pelas normasinternacionais.


• Realizar o executavel para a instalacao.

• Redigir o manual de instalacao, configuracao e manutencao do codigo desenvolvidopara cada tecnologia.

1.4 Contribuicoes do autor

Esta parte do relatorio descreve o trabalho atribuıdo pela equipa ao seu autor.Nos proximos capıtulos, o software que obtem as alteracoes das varias BDs, converte-

as para um formato padrao em JSON e envia-as para o intermediario Kafka para quesejam disponibilizadas as aplicacoes interessadas, sera chamado conector.

• Durante a fase de Analise realizou:

– o levantamento de requisitos.

– a comparacao entre as tecnologias existentes.

– a investigacao das funcionalidades suportadas pelos SGBD.

– a identificacao de problemas associados.

• Durante a fase de Desenho planeou:

– a arquitetura da solucao para cada tecnologia.

– a integracao com o sistema existente em producao na empresa de telecomunicacoes.

• Durante a fase de Desenvolvimento implementou:

– o conector SQL Server pos-2008.

– o conector MySQL pos v5.1.5.

• Durante a fase de Testes executou os testes:

– unitarios aos procedimentos e funcoes.

– de Integracao com o sistema desenvolvido pela equipa.

• Ao longo do projeto produziu:

– os comentarios adjacentes ao codigo desenvolvido.

– o manual de instalacao do conector MySQL [70].

– o manual de instalacao do conector SQL Server [71].

• Todas as tarefas referidas anteriormente contribuıram para a obtencao do produtofinal que:


– publica no intermediario Kafka as alteracoes captadas das BDs de producaoSQL Server e MySQL num formato JSON normalizado que pode ser enviadopara os subscritores segundo as suas preferencias.

1.5 Estrutura do documento

Em seguida apresentam-se os capıtulos e seccoes em que este documento esta divididoacompanhados de um breve resumo do conteudo de cada um deles.

Este documento esta organizado da seguinte forma:

• Capıtulo 2 – Estado da arte: pesquisa sobre os projetos e as funcionalidades dosSGBD que existem atualmente para o registo, obtencao, formatacao e publicacaode alteracoes em SQL Server e MySQL.

2.1 - Conector SQL Server: lista das funcionalidades incluıdas na linguageme dos conectores alternativos para publicar no intermediario Kafka as alteracoesregistadas pelo mecanismo CDC do SQL Server.

2.2 - Conector MySQL: lista das funcionalidades incluıdas na linguagem e dosconectores alternativos que recolham as alteracoes do registo binario e as publiquemno intermediario Kafka.

2.3 - Discussao: indicacao dos motivos para nao adotar uma das solucoes ana-lisadas.

• Capıtulo 3 – Analise: compreensao, descricao, contextualizacao e recolha dos re-quisitos do projeto.

3.1 - Descricao do projeto: em que consiste o projeto, missao, criticidade eotimizacao dos conectores, ciclo de vida dos dados manipulados, tecnologias e sis-temas envolvidos e o que se pretende obter.

3.2 - Requisitos detalhados: levantamento de requisitos funcionais, nao funci-onais, inversos, diagramas dos conectores desenvolvidos e do ambiente em que seinserem.

3.3 - Casos de uso: listam as utilizacoes mais comuns dos conectores.

3.4 - Diagramas de fluxos de dados: ilustra a manipulacao das alteracoes.

3.5 - Diagrama de transicao de estados dos conectores: sintetiza as fases dofuncionamento dos conectores.

3.6 - Diagramas de atividades: apresentam as tarefas realizadas pelo sistema econectores.


3.7 - Diagramas de sequencia: indicam a ordem das chamadas dos procedimen-tos e funcoes dos conectores.

3.8 - Diagramas de classes: demonstram a organizacao das tabelas em cada BD.

• Capıtulo 4 - Planeamento: enumeracao dos recursos humanos associados ao pro-jeto, das tecnologias envolvidas e das previsoes para este projeto. Indicacao doprocesso de desenvolvimento adotado e da organizacao das tarefas.

4.1 - Recursos: descricao dos recursos humanos e das tecnologias envolvidasneste projeto.

4.2 - Estimacao: do esforco disponıvel, com modelos empıricos e recorrendo adados historicos.

4.3 - Processo de desenvolvimento de software: descricao do modelo cascatautilizado.

4.4 - Planeamento detalhado do projeto: descricao textual do diagrama dastarefas do projeto (Gantt) sua decomposicao e afetacao.

4.5 - Analise crıtica: consideracoes sobre a viabilidade do projeto e apresentacaode possıveis solucoes para os problemas mais provaveis.

• Capıtulo 5 - Implementacao: lista dos procedimentos especificados, organizacaodos conectores e descricao das funcionalidades desenvolvidas.

5.1 - Especificacao de procedimentos: lista de solucoes para resolver os desa-fios apresentados pelos conectores.

5.2 - Organizacao do conector: descricao das tarefas especıficas dos varioscomponentes de cada conector.

5.3 - Funcionalidades do sistema: descricao detalhada das operacoes realizadaspor cada conector.

5.4 - Aspetos significativos da implementacao: lista da documentacao produ-zida com os detalhes da implementacao mais importantes para a instalacao, manutencaoe futuros desenvolvimentos.

• Capıtulo 6 - Testes: definicao da extensao dos testes pretendida e do plano de testesunitarios e de integracao. Descricao dos testes estruturais (caixa branca) e funcio-nais (caixa preta) aplicados para verificar a correta implementacao dos conectores.Apresentacao dos resultados da cobertura dos testes e dos erros detetados nos co-nectores.

6.1 - Plano de testes: descricao e categorizacao dos testes.

6.2 - Conclusoes dos testes: indicacao da cobertura alcancada e demonstracaodos dados obtidos numa lista de erros detetados em cada conector.


6.3 - Discussao: indicacao da criticidade dos erros identificados e avaliacao daaptidao dos conectores desenvolvidos.

• Capıtulo 7 - Conclusoes: descricao das tarefas realizadas e comparacao dos resul-tados obtidos com a organizacao de tarefas inicial, com o esforco estimado e com otrabalho requerido. avaliacao do trabalho desenvolvido, diferencas face as estima-tivas, analise do esforco despendido e do decurso do projeto, indicacao de futurosdesenvolvimentos e sıntese crıtica do projeto

7.1 - Decomposicao, atribuicao e calendarizacao das tarefas realizadas: apre-sentadas no diagrama Gantt na figura 3 em anexo.

7.2 - Planeado vs. executado: comparacao entre o trabalho planeado e aqueleque foi executado.

7.3 - Avaliacao post-mortem: lista dos aspetos positivos e negativos do projetoe comparacao entre a realidade do projeto e as estimativas iniciais.

7.4 - Sıntese crıtica do projeto: analise de todo o decurso do projeto e enumeracaode problemas identificados no projeto.

7.5 - Conclusao: balanco do projeto e consideracoes finais.

• Capıtulo 8 - Futuros desenvolvimentos: identificacao das funcionalidades que po-dem ser desenvolvidos para complementar o sistema.

Capıtulo 2

Estado da arte

Neste capıtulo sao apresentados os resultados de uma pesquisa por solucoes ja existen-tes, que procuram resolver problemas de integracao de dados similares ao deste projeto.

2.1 Conector SQL Server

Em seguida listam-se as funcionalidades e versoes de conectores relevantes encontra-dos na pesquisa para o conector SQL Server.

2.1.1 Funcionalidades incluıdas

A lista seguinte contem as funcionalides oferecidas pelo SGBD que podem auxiliar naconstrucao de um conector SQL Server.

• O registo das alteracoes ocorridas nas tabelas (ativar CDC) [61].

• O agendamento de execucao de codigo T-SQL (Schedule Job) [63].

• A conversao de dados relacionais para JSON (SQL Server 2016) [60, 62].

• A execucao de ferramentas na linha de comandos (executar na CMDShell) [64].

• A integracao de codigo C# para adicionar funcionalidades (ativar SQL CLR) [44].

• A ativacao de eventos gatilho quando se realiza uma determinada operacao na BDem producao [12].

• A conversao do formato de numeros e marcas temporais (timestamps) [10].

2.1.2 Versoes empresariais

As versoes seguintes sao alternativas empresariais ao conector SQL Server que se pre-tende desenvolver.

11

Capıtulo 2. Estado da arte 12

• Microsoft SQL Server CDC to intermediario Kafka – Striim [73].

• Oracle Goldengate to replicate SQL Server transactions [59].

• IBM InfoSphere Data Replication from SQL Server [16].

• Informatica PowerCenter [49].

• SAP NetWeaver Master Data Management (MDM)[68].

2.1.3 Versoes empresariais de codigo aberto

A versao seguinte e uma alternativa empresarial ao conector SQL Server cujo codigofoi disponibilizado publicamente para permitir o seu desenvolvimento e utilizacao pelacomunidade.

• Pentaho Data Integration (aka Kettle) [15].

2.1.4 Versoes particulares de codigo aberto

As versoes seguintes sao alternativas ao conector SQL Server que se deseja desenvolvere foram realizadas por particulares que as disponibilizaram em codigo aberto.

• GitHub - No9/sqlcdcstream: A stream of SQL Server Change Events [36].

• Is there a SQL Server CDC connector for intermediario Kafka Connect? - Gruposdo Google [26].

• intermediario Kafka connect: connecting ligacao a base de dados usando java - javadatabase connection (JDBC) source using Sql server - Grupos do Google [28].

• intermediario Kafka Connect - Is this the expected behavior? - Grupos do Google[27].

• GitHub - jpalomo/kafka-connect-mssqlserver-cdc [35].

Problemas detetados nos trabalhos relacionados com o conector SQL Server

A lista seguinte apresenta os problemas detetados nos trabalhos referidos anteriormentee que sao comparados na tabela 2.1.

• A: O preco de aquisicao da licenca de utilizacao.

• B: O projeto foi desenvolvido por uma empresa de um grupo concorrente.

• C: Nao mantem a compatibilidade requerida porque utiliza recursos adicionadosapos o SQL Server 2008.


• D: Nao mantem a compatibilidade requerida porque utiliza recursos das ultimasversoes do MySQL

• E: Implica alteracoes nas BD produtoras. Estas BD nao podem ser alteradas porqueja estao em producao.

• F: Nao garante funcionamento quase em tempo real.

• G: Falta de suporte para os tipos de colunas personalizados utilizados nas BD emproducao da empresa de telecomunicacoes [13].

• H: Acesso restrito ao codigo fonte.

• I: Utiliza codigo Java.

Tabela 2.1: Comparacao entre os trabalhos relacionados com o conector SQLServer

ProblemasBibliografia A B C D E F G H I

[73] X X X X[59] X X[16] X X[49] X X[68] X X X[15] X[36] X X[26] X[28] X X[27] X[35] X X X X

Problemas detetados nas funcionalidades incluıdas no SQL Server

Em seguida estao os problemas que condicionam a utilizacao das funcionalidades in-cluıdas no SQL Server para resolver alguns desafios do conector e a sua comparacao natabela 2.2.

• J: Nao mantem a compatibilidade requerida porque utiliza recursos adicionados noSQL Server 2012.

• L: Nao mantem a compatibilidade requerida porque utiliza recursos adiconados noSQL Server 2016.

• M: Implica alteracoes nas BD produtoras. Estas BD nao podem ser alteradas porqueja estao em producao.


• N: Nao garante funcionamento quase em tempo real.

• O: Estao bloqueados pelo administrador das BDs porque originam problemas deseguranca bem conhecidos como a:

O1: execucao de programas na linha de comandos do Windows.

O2: execucao de bibliotecas C# pre-compiladas.

O3: exportacao de dados por protocolo de transferencia de dados - hypertexttransfer protocol (HTTP).

Tabela 2.2: Comparacao entre as funcionalidades existentes no SQLServer

ProblemasBibliografia J L M N O1 O2 O3

[61] X[63] X

[60, 62] X[64] X[44] X X[12] X[10] X

2.2 Conector MySQL

Em seguida listam-se as funcionalidades e versoes de conectores relevantes encontra-dos na pesquisa para o conector MySQL.

2.2.1 Funcionalidades incluıdas

A lista seguinte contem as funcionalidades disponibilizadas pelo SGBD que podemauxiliar na construcao de um conector MySQL.

• As colunas podem ser do tipo JSON e podem ser utilizadas as funcoes JSON AR-RAY([val[, val] ...]), JSON OBJECT([key, val[, key, val] ...]) e JSON QUOTE(string)para o formatar [4].

• O registo binario num ficheiro dos dados alterados nas tabelas [5].

• O registo binario num ficheiro das operacoes realizadas nas tabelas [6].


2.2.2 Versoes empresariais

As versoes seguintes sao alternativas empresariais ao conector MySQL que se pretendedesenvolver.

• MySQL CDC to intermediario Kafka – Striim [74].

• IBM DataStage ODBC to MySQL [58].

2.2.3 Versoes empresariais de codigo aberto

As versoes listadas em seguida sao alternativas empresariais ao conector MySQL queforam disponibilizadas em codigo aberto para permitir o seu desenvolvimento e utilizacaopela comunidade.

• GitHub - vmware/tungsten-replicator: Tungsten Replicator [42].

• GitHub - zendesk/maxwell: Maxwell’s daemon, a mysql-to-json intermediario Kafkaproducer [40, 66].

• GitHub - Yelp/mysql-streamer: MySQLStreamer is a database change data captureand publish system [39, 69].

• GitHub - debezium/debezium: Change data capture for a variety of databases [34,14].

• GitHub - shyiko/mysql-binlog-connector-java: MySQL Binary Log conector [38].

• Informatica Connector Toolkit: MySQL Connector [48].

2.2.4 Versoes particulares de codigo aberto

As versoes seguintes sao alternativas ao conector MySQL que se deseja desenvolver eforam realizadas por particulares que as disponibilizaram em codigo aberto.

• GitHub - mardambey/mypipe: MySQL binary log consumer with the ability to o onchanged rows and publish changes to different systems with emphasis on Apacheintermediario Kafka [41].

• GitHub - whitesock/open-replicator: Open Replicator is a high performance MySQLbinlog parser written in Java. It unfolds the possibilities that you can parse, filterand broadcast the binlog events in a real time manner [43].

• GitHub - pyr/recordbus: recordbus: mysql binlog to apache intermediario Kafka[37].


• GitHub - dan-da/cdc audit: change data capture via audit tables and triggers formysql [19].

• FlexCDC is a change data capture utility for MySQL 5.1 [75].

• GitHub - mysqludf/lib mysqludf json: A UDF library of functions to map MySQLdata to JSON [20].

Problemas detetados nos trabalhos relacionados com o conector MySQL

Em seguida voltam a indicar-se as listas de problemas para facilitar a leitura das tabelasde comparacao 2.3 e 2.4. Continua-se a sequencia das letras das listas do conector SQLServer porque nao se pretende comparar o conector SQL Server com o MySQL uma vezque e necessario integrar dados de ambas as tecnologias.

A lista seguinte apresenta os problemas detetados nos trabalhos referidos anterior-mente e que sao comparados na tabela 2.3.

• P: O preco de aquisicao da licenca de utilizacao.

• Q: O projeto foi desenvolvido por uma empresa de um grupo concorrente.

• R: Nao mantem a compatibilidade requerida porque utiliza recursos das versoes doMySQL pos 5.5, como:

- o identificador unico (GTID) [65].

• S: Implica alteracoes nas BD produtoras. Estas BD nao podem ser alteradas porqueja estao em producao.

• T: Utiliza recursos da BD em producao que estao bloqueados pelo administradordas BDs porque constituem problemas de seguranca, como:

- a execucao de programas na linha de comandos do Windows.

- a exportacao de dados por HTTP.

• U: Nao garante funcionamento quase em tempo real.

• V: Utiliza codigo Java.

• X: Nao suporta todas as operacoes sobre as BD que sao utilizadas pelos sistemasem producao.

• Z: Utiliza codigo Python.

• AA: Utiliza PHP.

• AB: Utiliza gatilhos [56].


• AC: Nao mantem a compatibilidade requerida porque utiliza recursos das versoesdo MySQL pos 5.1.

• AD: Acesso restrito ao codigo fonte.

Tabela 2.3: Comparacao entre os trabalhos relacionados com o conector MySQL

ProblemasBibliografia P Q R S T U V X Z AA AB AC AD

[74] X X X[58] X X[42] X X

[40, 66] X X X X[39, 69] X X[14, 34] X X X

[38] X X X[48] X[41] X[43] X X[37] X X[19] X X X X[75] X X X[20] X

Problemas detetados nas funcionalidades incluıdas no MySQL

Em seguida estao os problemas que condicionam a utilizacao das funcionalidades dis-ponibilizadas pelo MySQL para resolver alguns desafios do conector e a sua comparacaona tabela 2.4.

• AD: O tipo JSON e as funcoes que o formatam nao permitem a retrocompatibili-dade com as BD com versoes anteriores a agosto de 2015. [4].

• AE: O registo binario dos dados alterados nas tabelas nao permite a retrocompati-bilidade com as BD com versoes anteriores a novembro de 2008. [6].

• AF: O registo binario das operacoes realizadas nas tabelas nao permite a retrocom-patibilidade com as BD com versoes anteriores a janeiro de 2001. [5].

2.3 Discussao

Devido aos problemas identificados nos trabalhos relacionados e nas funcionalida-des existentes conclui-se que e necessario desenvolver os conectores para SQL Server


Tabela 2.4: Comparacao entre as funcionalidades existentes no MySQL

ProblemasBibliografia AD AE AF

[4] X[6] X[5] X

e MySQL. Nem todos os problemas identificados tem a mesma relevancia uma vez que opreco de aquisicao e suficiente para impedir a sua utilizacao neste projeto mas a falta desuporte ou de retrocompatibilidade podera ser adaptada.

Nao foi adoptada a solucao proposta em nenhum dos trabalhos relacionados masutilizaram-se e adaptaram-se algumas funcionalidades disponibilizadas pelos SGBD.

No conector SQL Server utilizou-se o registo de alteracoes nas tabelas, a integracaode codigo C# e a conversao do formato das marcas temporais.

No conector MySQL adaptou-se a funcionalidade de registo binario das alteracoes [6],convertendo o ficheiro binario que esta produz para texto legıvel utilizando a ferramentado SGBD mysqlbinlog [3] e pesquisando as alteracoes nesse texto. Como descrito noscasos especiais de instalacao do manual de instalacao do conector MySQL [70], tambeme possıvel implementar o conector tendo apenas o registo binario de operacoes. Para taldeve ser utilizada uma BD auxiliar que seja uma replica da que esta em producao onde seapliquem todas as operacoes que surjam no ficheiro de registo binario.

Capıtulo 3

Analise

Em seguida e fornecida uma descricao detalhada deste projeto acompanhada pelos re-quisitos que foram identificados para auxiliar a compreensao dos desafios impostos poreste projeto.

3.1 Descricao do projeto

Neste projeto pretende substituir-se o sistema antigo por um mais atual que satisfacaos requisitos dos novos servicos. Como os sistemas produtores ja possuem os propriosmecanismos de detecao e tolerancia a faltas o mais importante e disponibilizarem-se osfluxos de dados recolhidos quase em tempo real, preferencialmente entre dez a quinzeminutos.

Apesar de serem recolhidos dados provenientes de sistemas crıticos para a prestacaode servicos de telecomunicacoes aos clientes, e suficiente obte-los, integra-los e publica-los em intervalos de dez a quinze minutos pois a sua utilizacao resume-se ao processa-mento por consumidores antigos e por novos consumidores que venham a ser desenvolvi-dos.

Preve-se que os novos consumidores poderao alimentar um sistema complementar dediagnostico quase em tempo real da qualidade do servico prestado aos clientes e armaze-narao todos os dados recolhidos para criar um armazem de dados onde se possam aplicartecnicas de prospecao de dados. Os sistemas que subscrevem e analisam os dados inte-grados nao foram desenvolvidos neste projeto estando portanto para alem do ambito destedocumento.

Para cumprir o proposito do sistema e necessario desenvolver conectores CDC (ChangeData Capture) para Oracle, SQL Server e MySQL porque neste momento a empresa multi-nacional de telecomunicacoes nao utiliza outras tecnologias de BD. Estes deverao funcio-nar em segundo plano para nao afetar os sistemas em operacao e ser pouco intrusivos paraevitar alteracoes frequentes. Para cumprir estes requisitos, os procedimentos e as funcoesdesenvolvidos foram otimizados para realizarem apenas as operacoes estritamente ne-

19

Capıtulo 3. Analise 20

cessarias e sempre que possıvel foram utilizados os mecanismos disponibilizados pelosSGBD.

A missao de cada conector e detetar todas as alteracoes que ocorrerem nas tabelasem producao que lhe sejam indicadas. Por ultimo, convertem os dados alterados paraformato JSON e publicam-nos no intermediario Kafka considerando as varias especifici-dades de cada SGBD descritas neste relatorio. Para realizar estas publicacoes a equipa dedesenvolvimento escolheu o interface Kafka-REST-Proxy (consumidor JSON). Esta foiconsiderada a alternativa mais estavel que cumpria os requisitos identificados para esteprojeto evitando assim alocar mais tempo para desenvolver uma nova interface com ointermediario Kafka.

3.2 Requisitos detalhados

Em seguida listam-se os requisitos para os conectores. Foram identificados e siste-matizados com a equipa que iniciou este projeto pois o modelo em cascata seguido naoprevia mais fases de analise com o cliente.

3.2.1 Requisitos funcionais

Estes sao os requisitos funcionais dos conectores:

C-Requisitos

Esta e a lista dos requisitos dos clientes:

• CRF1 - Manter a retrocompatibilidade do conector com as BD em producao.

- Pos SQL Server 2008.

- Pos MySQL 5.1.5.

• CRF2 - Detetar alteracoes nas BD em producao.

• CRF3 - Obter alteracoes sem interferir com o funcionamento dos sistemas emproducao.

D-Requisitos

Esta e a lista dos requisitos dos programadores:

• DRF1 - Converter alteracoes para um formato padrao (JSON) escolhido pela equipaque considerava o XML muito prolixo.

• DRF2 - Exportar alteracoes para um intermediario Kafka quase em tempo real.


• DRF3 - Testar o funcionamento de todo o sistema de integracao e analise com osconectores desenvolvidos:

- Utilizar dados open source num ambiente muito dinamico com milhares deoperacoes por segundo em centenas de tabelas.

3.2.2 Requisitos nao funcionais

Estes sao os requisitos nao funcionais dos conectores:

1. Referentes ao seu desempenho:

• RNF1 - a velocidade: para obter, analisar e persistir milhares de operacoes empoucos minutos (de preferencia 5 a 10 minutos).

• RNF2 - a capacidade: para exportar as alteracoes detetadas em quantidadesindexadas a capacidades restritas dos sistemas em producao.

• RNF3 - a utilizacao de memoria: deve ser minimizada utilizando mecanismosde registo de alteracoes embutidos nas BD em producao.

• RNF4 - o tempo de resposta: deve suportar a transmissao de fluxos de dadosem poucos minutos e possibilitar a satisfacao de requisitos proximos de temporeal.

2. Referentes as suas interfaces:

• RNF5 - de hardware: devem ser configuradas para utilizar uma ligacao fısicaa rede (Ethernet).

• RNF6 - de software: devem comunicar por HTTP usando JSON e o protocolointermediario Kafka.

• RNF7 - do SGBD: para receber comandos linguagem de consulta estrutu-rada - structured query language (SQL) enviados por um operador e executarPL/SQL para registar e exportar as alteracoes ocorridas.

• RNF8 - de armazenamento: para receber as alteracoes por HTTP.

• RNF9 - de comunicacoes: devem ser realizadas por HTTP via Ethernet.

3. Referentes a utilizacao dos recursos disponıveis, estes sao os limites maximos quenao deve ultrapassar num sistema em producao:

• RNF13 - Processamento: 10% do CPU.

• RNF14 - Memoria: 10% da RAM.

• RNF15 - Disco: 10% do HDD.

• RNF16 - Rede: 10% da ligacao Ethernet.


3.2.3 Requisitos inversos

Estes sao os requisitos inversos dos conectores, que referem aquilo que nao e da res-ponsabilidade deles:

1. Nao conhecem o destino final das alteracoes pois apenas as publicam no inter-mediario Kafka definido.

2. Nao analisam as alteracoes detetadas nas BD em producao para o qual foram de-senvolvidos.

3.3 Casos de uso

Em seguida apresentam-se os casos de uso mais comuns em que o sistema utiliza osconectores para formatar o JSON das alteracoes das BD em producao.

Todos os fluxos principais de eventos terminam com:

• o sistema a guardar os dados resultantes do pedido realizado pelo ator numa BD emproducao.

• o conector a capturar, formatar e publicar as alteracoes registadas no intermediarioKafka.

• um sistema recetor a obter as alteracoes do intermediario Kafka segundo as suasconfiguracoes personalizadas.

1. Efetuar uma chamada

• Atores:

– o cliente.

• Pre-condicoes:

– o cliente possui telefone ou telemovel.

– o cliente subscreveu um servico que lhe permite utilizar esse equipamentopara realizar chamadas.

• Fluxo principal de eventos:

– o cliente telefona para um numero.

– o sistema realiza a chamada.

2. Aceder a uma pagina na internet

• Atores:


– o cliente.

• Pre-condicoes:

– o cliente possui um dispositivo que lhe permite aceder a internet.

– o cliente subscreveu um servico que lhe permite utilizar esse dispositivopara aceder a internet.

– o cliente tem o seu dispositivo ligado a internet.


– o cliente abre um navegador da internet no seu dispositivo.

– o cliente pede para aceder a uma pagina na internet.

– o sistema permite ao cliente aceder a pagina.

3. Adquirir pacotes de dados moveis

• Atores:

– o cliente.

• Pre-condicoes:

– o cliente possui um dispositivo movel.


– o cliente liga para o atendimento automatico.

– o sistema apresenta as opcoes ao cliente.

– o cliente indica qual o pacote movel que pretende adquirir.

4. Assistir a um canal transmitido em direto

• Atores:

– o cliente.

• Pre-condicoes:

– o cliente possui um dispositivo que reproduz vıdeo.

– o dispositivo esta ligado a rede da empresa de telecomunicacoes.


– o cliente pede a lista de canais disponıveis.

– o sistema apresenta a lista de canais.

– o cliente seleciona o canal a que pretende assistir.

5. Rever um programa transmitido nos ultimos dias

• Atores:


– o cliente.

• Pre-condicoes:

– o cliente possui um dispositivo que recebe programas transmitidos.

– o cliente subscreveu um servico que lhe permite assistir aos programastransmitidos nos ultimos dias.

– o dispositivo esta ligado a rede da empresa de telecomunicacoes.


– o cliente pede a lista de programas disponıveis.

– o sistema apresenta a lista de programas.

– o cliente seleciona o programa a que pretende assistir.

6. Sincronizar conteudos multimedia entre a televisao e um dispositivo movel

• Atores:

– o cliente.

• Pre-condicoes:

– o cliente possui uma televisao e um dispositivo movel.

– o cliente subscreveu um pacote de canais para a televisao.

– o dispositivo movel esta junto a televisao.


– o cliente pede a lista de conteudos disponıveis na televisao.

– o sistema apresenta os conteudos armazenados.

– o cliente seleciona o conteudo que pretende sincronizar.

7. Mudar o tarifario do telemovel na area de cliente

• Atores:

– o cliente.

• Pre-condicoes:

– o cliente possui um dispositivo que pode aceder a internet.

– o cliente subscreveu um servico que lhe permite utilizar esse dispositivopara aceder a internet.

– o cliente tem o seu dispositivo ligado a internet.

– o cliente possui telefone ou telemovel.

– o cliente subscreveu um tarifario que lhe permite utilizar esse equipa-mento para realizar chamadas.


– o cliente tem acesso a uma area de cliente disponibilizada pela empresade telecomunicacoes.


– o cliente abre um navegador da internet no seu dispositivo.

– o cliente acede a sua area de cliente na pagina da empresa de telecomunicacoes.

– o cliente escolhe outro tarifario na lista de tarifarios disponıveis.

– o sistema confirma a mudanca do tarifario do cliente.

8. Adquirir um filme na aplicacao domestica ou movel

• Atores:

– o cliente.

• Pre-condicoes:

– o cliente possui um aparelho que lhe permite assistir a televisao digital.

– o cliente subscreveu um servico que lhe permite utilizar esse aparelhopara adquirir filmes num videoclube digital.


– o cliente abre uma lista de filmes no seu aparelho.

– o cliente escolhe e compra um filme da lista.

– o sistema disponibiliza o filme.

9. Registar uma nova instalacao

• Atores:

– um tecnico de telecomunicacoes.

• Pre-condicoes:

– o tecnico instalou um servico da empresa de telecomunicacoes a um cli-ente.

– o tecnico tem o seu dispositivo movel ligado a internet.

– o tecnico tem acesso ao sistema de registo de novas instalacoes.


– o tecnico preenche os dados de uma nova instalacao.

– o tecnico regista uma nova instalacao no sistema.

– o sistema confirma o registo da nova instalacao.

10. Registar um novo cliente

• Atores:


– um assistente.

• Pre-condicoes:

– o assistente trabalha numa loja fısica da empresa de telecomunicacoes.

– o assistente tem um computador ligado a internet.

– o assistente tem acesso ao sistema de registo de novos clientes.


– o assistente preenche os dados do novo cliente.

– o assistente regista um novo cliente no sistema.

– o sistema confirma o registo do novo cliente.

11. Atualizar uma instalacao domestica pre-existente

• Atores:


• Pre-condicoes:

– o tecnico alterou os servicos prestados pela empresa de telecomunicacoesa um cliente.

– o tecnico tem o seu dispositivo movel ligado a internet.

– o tecnico tem acesso ao sistema de registo de alteracoes.


– o tecnico pesquisa o cliente.

– o sistema apresenta os dados da instalacao antiga.

– o tecnico atualiza os dados com as alteracoes que realizou.

– o sistema confirma a atualizacao dos servicos do cliente.

12. Disponibilizar o vıdeo de varias camaras num evento

• Atores:


• Pre-condicoes do tecnico:

– verificou o funcionamento das varias camaras.

– tem uma ligacao a internet de ultima geracao.

– tem o seu dispositivo movel ligado a internet.

– tem acesso ao sistema de transmissao de vıdeo.


– o tecnico regista uma nova transmissao.


– o sistema verifica as condicoes da rede.

– o tecnico inicia a transmissao.

– o sistema confirma que a transmissao se esta a realizar com sucesso.

– o tecnico termina a transmissao.

13. Mudar o tarifario de um cliente por telefone

• Atores:

– um cliente.

– um telefonista.

• Pre-condicoes:

– o telefonista trabalha numa central de atendimento.

– o telefonista tem um computador ligado a internet.

– o telefonista tem acesso ao sistema com as areas dos clientes.

– o cliente subscreveu um servico da empresa de telecomunicacoes.


– o cliente telefona para a central de atendimento.

– o cliente fornece os seus dados pessoais ao telefonista.

– o telefonista pesquisa a conta do cliente.

– o cliente indica o tarifario que pretende.

– o telefonista muda o tarifario do cliente no sistema.

– o sistema confirma a mudanca do tarifario do cliente.

14. Adicionar um novo tarifario

• Atores:

– um tecnico de suporte.

• Pre-condicoes:

– o tecnico trabalha na equipa de suporte da empresa de telecomunicacoes.

– o tecnico tem acesso ao sistema para realizar a sua manutencao.

– o tecnico recebe os dados do novo tarifario.


– o tecnico insere os dados do novo tarifario.

– o tecnico adiciona o novo tarifario ao sistema.

– o sistema confirma a adicao do novo tarifario.


3.4 Diagramas de fluxos de dados

Estes diagramas permitem observar as transformacoes realizadas sobre os dados cap-turados pelos conectores.

Os produtores de dados representados nos diagramas sao os aparelhos domesticos detelecomunicacoes e as lojas de vendas ou apoio ao cliente. Estes alteram dados nas BDsem producao e sao maioritariamente sistemas proprietarios da empresa de telecomunicacoesou sistemas adquiridos a Ericsson 1, Cisco 2 e CGI 3.

O intermediario Kafka situa-se entre publicadores e subscritores permitindo-lhes res-petivamente escrever e ler fluxos de dados. Os dados publicados sao armazenados deforma persistente e tolerante a faltas. O seu funcionamento num grupo de maquinas(cluster) permite-lhe oferecer uma boa escalabilidade e suportar fluxos de comunicacaoem tempo real.

Figura 3.1: Diagrama de Fluxos de Dados do Sistema nıvel 0

1Communication Services - Ericsson, https://www.ericsson.com/ourportfolio/digital-services-solution-areas/communication-services

2Managed Services - Cisco, https://web.archive.org/web/20180730203455/https://www.ericsson.com/ourportfolio/digital-services-solution-areas/communication-services

3Customer Service and Billing: Telco and Media - CGI UK, https://www.cgi-group.co.uk/solutions/mass-data-billing/telecommunications


No diagrama de fluxos de dados de nıvel 0, figura 3.1, e possıvel observar que asalteracoes provenientes dos produtores sao convertidas para o formato JSON e publicadasno intermediario Kafka.

Figura 3.2: Diagrama de Fluxos de Dados do Sistema nıvel 1

No diagrama de fluxos de dados de nıvel 1, figura 3.2, esta representada a capturadas alteracoes das BDs de producao, a utilizacao de uma base de dados auxiliar paracada conector para estes obterem parametros de configuracao e manterem os dados dasultimas alteracoes sem sobrecarregarem as BDs de producao, e a publicacao do JSON nointermediario Kafka depois de formatado.

Com a continuacao do funcionamento dos conectores espera-se que, quando tiveremsido capturadas alteracoes em todas as linhas, as tabelas auxiliares se tornem replicas dasque estao em producao.

No diagrama de fluxos de dados Oracle, figura 3.3, descrevem-se as operacoes internas


Figura 3.3: Diagrama de Fluxos de Dados da BD Oracle nıvel 2


realizadas pelo conector desenvolvido pela equipa, desde a rececao das notificacoes dasalteracoes, a obtencao das mesmas seguida do seu registo numa tabela auxiliar e posteriorconversao para publicacao no intermediario Kafka.

O conector Oracle foi desenvolvido pela equipa mas foi analisado neste projeto comoparte do sistema e inspiracao para a realizacao dos outros conectores.

No diagrama de fluxos de dados SQL Server, figura 3.4, e descrito o funcionamentointerno do conector com maior detalhe, nomeadamente a captura de dados a partir dastabelas auxiliares preenchidas pelo mecanismo de CDC integrado e a sua formatacao emJSON antes de ser publicado no intermediario Kafka.

No diagrama de fluxos de dados MySQL, figura 3.5, descrevem-se as operacoes inter-nas do conector que obtem as alteracoes a partir do ficheiro de registo binario atualizadopelo SGBD.

3.5 Diagrama de transicao de estados dos conectores

O diagrama na figura 3.6 apresenta as diversas fases do funcionamento dos conectores:desde a captura de alteracoes, a sua obtencao, conversao e publicacao. O estado em quese obtem as alteracoes inclui as pesquisas para as completar e a sua insercao nas tabelasauxiliares. Estas interacoes com as BDs nao foram representadas como estados pois saorealizadas quando o conector esta a obter alteracoes. Como a publicacao de alteracoesno intermediario Kafka nao bloqueia os conectores, eles podem esperar mais alteracoessempre que existam atrasos.

3.6 Diagramas de atividades

O diagrama de atividades geral, na figura 3.7, ilustra as atividades realizadas pelo sis-tema para receber as publicacoes dos conectores e entrega-las aos subscritores conformeas suas preferencias. Nos diagramas seguintes que sao especıficos de cada tecnologia debase de dados e possıvel observar as atividades realizadas por cada um dos conectoresantes de formatarem e publicarem o JSON.

No diagrama de atividades do conector Oracle desenvolvido pela equipa, figura 3.8, epossıvel observar a utilizacao da funcionalidade disponibilizada pelo SGBD Oracle Noti-fications para conhecer que linhas sao alteradas.

No diagrama de atividades do conector SQL Server, figura 3.9, observa-se a im-portancia das atividades realizadas pelo mecanismo de captura de dados (CDC) disponi-bilizado pelo SGBD para detetar e registar as alteracoes em tabelas auxiliares. O conectortem a responsabilidade de identificar as que ainda nao foram enviadas para o intermediarioKafka, formatar o JSON e publica-las.

No diagrama de atividades do conector MySQL, figura 3.10, e visıvel que este obtem


Figura 3.4: Diagrama de Fluxos de Dados da BD SQL Server nıvel 2


Figura 3.5: Diagrama de Fluxos de Dados da BD MySQL nıvel 2


Figura 3.6: Diagrama de Transicao de Estados dos Conectores


as alteracoes previamente registadas pelo SGBD no ficheiro de log binario e consulta asBD para completar os dados recolhidos.

O diagrama do conector Oracle foi incluıdo para realcar as diferencas entre os variosconectores que resultaram das especificidades de cada tecnologia de base de dados.

3.7 Diagramas de sequencia

Nos diagramas de sequencia e possıvel observar a ordem das chamadas executadaspelos procedimentos e funcoes de cada conector que culminam no envio das alteracoesem formato JSON para o intermediario Kafka.

O diagrama do conector Oracle, figura 3.11, foi incluıdo para realcar as diferencas en-tre as chamadas especıficas de cada conector e permite observar as notificacoes enviadaspelo SGBD ao conector PL/SQL desenvolvido pela equipa.

O diagrama do conector SQL Server, figura 3.12, ilustra a pesquisa de alteracoes nastabelas auxiliares preenchidas pelo SGBD enquanto o do MySQL apresenta a pesquisa noficheiro de log binario e na BD para reunir todos os dados sobre as alteracoes.

O diagrama do conector MySQL, figura 3.13, permite observar que o conector pes-quisa o registo binario de alteracoes, que ja e realizado por defeito nas versoes mais recen-tes, para obter as ultimas alteracoes que depois completa com uma pesquisa nas tabelas.

3.8 Diagramas de classes

Estes diagramas permitem observar a organizacao das tabelas em cada BD.

• Os diagramas UML das tabelas nas BDs sao:

- o diagrama da BD auxiliar dos conectores, figuras 3.14, 3.15, 3.16 onde estesguardam:

- as linhas alteradas.

- as informacoes do mecanismo de captura de dados (CDC).

- os parametros de configuracao dos conectores.

- os diagramas de exemplo das tabelas existentes nas BDs em producao nasfiguras 1 e 2 em anexo.

• Nas tabelas onde existem reticencias apos o nome das colunas [67], a quantidadetotal de colunas e variavel pois depende das colunas da tabela de producao onde sedetetam alteracoes.


Figura 3.7: Diagrama de Atividades Geral do Sistema


Figura 3.8: Diagrama de Atividades do Conector Oracle


Figura 3.9: Diagrama de Atividades do Conector SQL Server


Figura 3.10: Diagrama de Atividades do Conector MySQL


Figura 3.11: Diagrama de Sequencia do Conector Oracle

Figura 3.12: Diagrama de Sequencia do Conector SQL Server


Figura 3.13: Diagrama de Sequencia do Conector MySQL

Figura 3.14: Diagrama de Classes do Conector Oracle


Figura 3.15: Diagrama de Classes do Conector SQL Server

Figura 3.16: Diagrama de Classes do Conector MySQL

Capıtulo 4

Planeamento

Seguidamente sera apresentado o planeamento do projeto, desde os recursos humanose as tecnologias envolvidas ate ao modelo de desenvolvimento utilizado e a distribuicaode tarefas.

4.1 Recursos

Os recursos associados ao projeto sao os mencionados nas proximas seccoes.

4.1.1 Recursos humanos

• As pessoas envolvidas foram:

– o autor que ficou responsavel pelo desenvolvimento dos conectores SQL Ser-ver e MySQL e testes do sistema.

– os membros da equipa de desenvolvimento do sistema.

• O esforco do autor iniciou-se em janeiro e terminou em setembro: 8h por dia e 5dias por semana durante 9 meses, como visıvel no diagrama de alocacao de recur-sos, figura 4.1.

• A organizacao da equipa foi:

– o autor que desenvolveu os conectores para as BD SQL Server e MySQL e re-alizou os testes ao sistema seguindo as indicacoes da equipa que desenvolveuo conector para as BD Oracle e os outros componentes do sistema.

• As justificacoes para o esforco do autor e para a organizacao ja referida resultam:

– da candidatura a este projeto apenas na segunda fase.

– da equipa de desenvolvimento do sistema ja nao estar alocada a este projeto atempo inteiro porque ja concluıram a sua parte do trabalho.

43

Capıtulo 4. Planeamento 44

– na lista das tarefas em que se divide este trabalho e no tempo previsto paracada uma que estao apresentados no diagrama Gantt, figura 3 em anexo nofinal deste documento.

4.1.2 Tecnologias envolvidas

Na proxima lista estao presentes todas as tecnologias envolvidas no trabalho.

No ambito do projeto

• Os servidores que contribuem para a persistencia dos dados capturados pertencema uma estrutura (framework) de processamento distribuıdo (Hadoop) :

– consumidor JSON: que estabelece a ligacao entre PL/SQL e o intermediarioKafka traduzindo JSON enviado por HTTP para o protocolo do intermediarioKafka.

– intermediario Kafka: que e o local onde se publicam, subscrevem, processame persistem as alteracoes convertidas para JSON pelo conector.

– escalonador de tarefas (Oozie): que e a agenda de trabalhos Hadoop.

– sistema de ficheiros Hadoop - Hadoop File System (HDFS): que e o sistemautilizado para guardar os ficheiros.

– HIVE: que e o local onde se persistem todos os dados publicados pelos conec-tores.

– interface Web de analise de dados (HUE): que e a interface web para analisaros dados integrados.

– gestor de recursos (YARN) com MapReduce2: que e o gestor de recursos ea agenda de trabalhos Hadoop com biblioteca de processamento de grandesquantidades de dados.

– servico de informacoes de configuracao (ZooKeeper): que e o servico deinformacoes de configuracao, sincronizacao e registo de nomes.

No ambito do conector

• Os servidores de BDs em producao sao:

– Oracle SQL: BD Oracle.

– SQL Server: BD Microsoft.

– MySQL: BD OpenSource/Oracle.

• As linguagens utilizadas nos conectores sao:


– SQL.

– PL/SQL.

– T-SQL.

– C#.

– C.

• Os ambientes de desenvolvimento onde se implementaram os conectores sao:

– Oracle SQL Developer.

– Microsoft SQL Server Management Studio.

– MySQL Workbench.

– Visual Studio.

– CodeBlocks.

Tabela 4.1: Competencias previas nas linguagens utilizadas

Linguagem SQL PL/SQL e T/SQL Java C# CDomınio Bom Muito reduzido Bom Muito reduzido Bom

4.2 Estimacao

Em seguida sao apresentadas as estimacoes para este trabalho.

4.2.1 Do esforco disponıvel

O autor deste projeto esta disponıvel:

8(horas) ∗ 22(dias) ∗ 9(meses) = 1584(horas)

4.2.2 Modelos empıricos (COCOMO)

Esta e a estimacao utilizando o modelo empırico Constructive Cost MOdel (COCOMO):

• num Projeto Organico a equipa e a dimensao do projeto sao reduzidas.

- Estas sao as constantes caracterısticas deste tipo de projeto:

a = 2.4; b = 1.05; c = 2.5; d = 0.38


Tabela 4.2: Estimacao por decomposicao de linhas de codigo

No de linhas Otimista Provavel PessimistaComponentes do sistema - - -

SQL Server: - - -Detecao de alteracoes 5 10 20

Obtencao de alteracoes 20 30 45Exportacao de alteracoes 35 50 100

MySQL: - - -Detecao de alteracoes 5 10 20

Obtencao de alteracoes 20 30 45Exportacao de alteracoes 35 50 100

• O modelo de equacoes Basico permite determinar o esforco com base na dimensaodo software (numero de linhas de codigo).

• Foram utilizadas as equacoes seguintes para calcular:

- o numero de linhas de codigo em milhares:

KLDC = LDC/1000

- o esforco em pessoas X mes:

Esforco = a ∗KLDCb

- a duracao em meses de desenvolvimento e:

Duracao = c ∗ Esforcod

• Os calculos realizados recorrendo as equacoes anteriores:

LDC = 230

KLDC = 230/1000 = 0.23

Esforco = 2.4 ∗ 0.231.05 = 0.513

Duracao = 2.5 ∗ 0.5130.38 = 1.099

• Os resultados deste metodo de estimacao sao:

- o esforco para realizar estes conectores e de 0.5 pessoas X mes.

- a duracao e de aproximadamente 1 mes.

Os resultados deste metodo sugerem que os conectores poderiam ser concretizadosrapidamente porque apenas dizem respeito ao desenvolvimento dos conectores e nao es-timam o tempo dedicado a sua analise, desenho e testes.


4.2.3 Dados historicos

• Um programador experiente demorou 10 dias a desenvolver as 724 linhas de codigoPL/SQL do conector Oracle

Mantem-se a estimativa dos 10 dias para desenvolver cada conector devido a menorexperiencia indicada na tabela 4.1 e considerando que a estimacao por decomposicao delinhas de codigo indicada na tabela 4.2 estima que sera possıvel desenvolver os conectoresSQL Server e MySQL em menos linhas de codigo .

4.3 Processo de desenvolvimento de software

O projeto foi desenvolvido seguindo um modelo cascata. Desenvolveu-se o conectorSQL Server e em seguida o conector MySQL. Ate se realizarem os testes de integracao,todas as fases foram realizadas especificamente para cada conector.

4.4 Planeamento detalhado do projeto

Em seguida apresenta-se o planeamento para este projeto.

4.4.1 Decomposicao das tarefas

A decomposicao das tarefas e a seguinte:

1. a Analise, o Desenho, o Desenvolvimento e os Testes Unitarios aos conectores:

(a) - Oracle.

(b) - SQLServer.

(c) - MySQL.

2. Os testes de integracao do sistema.

4.4.2 Afetacao das tarefas

A afetacao das tarefas necessarias para concretizar os conectores e a seguinte:

• a tarefa 1.a ja esta concluıda e o autor tem acesso ao codigo deste conector.

• as tarefas 1.b, 1.c e 2. foram atribuıdas ao autor deste relatorio.


4.4.3 Diagrama Gantt

No diagrama Gantt na figura 3, em anexo no final deste documento, e possıvel observar:

• a ordem das tarefas seguindo um modelo cascata de desenvolvimento de software.

• as precedencias de cada tarefa.

• que as tarefas tem precedencias, logo qualquer atraso na analise, no desenho ou naimplementacao provoca atrasos nos testes.

• que os testes sao a etapa em que se despende mais tempo.

• que o controlo de qualidade e a etapa em que se despende menos tempo.

4.4.4 Diagrama da alocacao de recursos

No diagrama da alocacao de recursos, figura 4.1, e possıvel observar o numero de horasprevisto para o autor realizar cada tarefa ao longo dos meses em que decorreu o projeto.

4.5 Analise crıtica

4.5.1 Viabilidade

Neste projeto a viabilidade e elevada uma vez que foi previamente definida a arquiteturado sistema, configurados a maioria dos componentes e desenvolvido o conector Oracle poruma equipa muito experiente.

4.5.2 Solucoes

Caso surjam dificuldades graves que possam impedir o cumprimento do planeamentopodera ser necessario aumentar o esforco previsto inicialmente para o autor deste re-latorio.


Figura 4.1: Diagrama da Alocacao de Recursos

Capıtulo 5

Implementacao

Neste capıtulo apresentam-se os procedimentos utilizados para resolver os desafios co-locados pelos conectores e a sua organizacao interna que foi desenhada para facilitar asua manutencao e reutilizacao. Em seguida enumeram-se as funcionalidades disponibili-zadas pelo sistema utilizando o trabalho realizado pelos conectores. Reunem-se assim osaspetos mais significativos mencionados nos documentos tecnicos [71] e [70].

5.1 Especificacao de procedimentos

Os procedimentos mais relevantes para a concretizacao dos conectores SQL Server eMySQL sao:

• o registo de alteracoes nas BD em producao que:

- atribui um identificador unico para detetar alteracoes repetidas.

- controla a ultima marca temporal registada para otimizar as pesquisas.

• a conversao de alteracoes nas tabelas e no ficheiro de log binario para JSON variadependendo dos tipos das colunas. Se forem:

- numeros decimais: deteta-se o numero de casas decimais para utilizar a pre-cisao correta.

- sequencias de caracteres (Strings): tratam-se os caracteres especiais apresen-tados na tabela 5.2.

- marcas temporais: convertem-se para um formato padrao internacional (YYYY-MM-DDTHH:MM:SS). [54] [55]

- outros tipos nao suportados: envia-se o nome da coluna e o valor a NULL,por exemplo: tipos de grandes dimensoes como BLOB ou FLOAT.

• a exportacao de alteracoes das tabelas SQL Server usando:

- SQL common language runtime (SQLCLR): para utilizar bibliotecas C#.

51

Capıtulo 5. Implementacao 52

- acesso SQL a linha de comandos (SQLCMD): para executar programas, comoa ferramenta para transferencia de dados (cURL) [18], no interpretador de linha decomandos.

• a exportacao de alteracoes do ficheiro de log binario MySQL:

- executando o programa cURL no interpretador de linha de comandos.

5.2 Organizacao do conector

Em seguida apresenta-se a organizacao dos conectores que compoem este sistema.

5.2.1 Conector Oracle

A organizacao do conector Oracle desenvolvido pela equipa e utilizado como referenciaconsiste em:

• configurar as notificacoes Oracle para as tabelas em que se pretende capturar alteracoes.

• receber as notificacoes lancadas pelo SGBD.

• capturar as alteracoes das tabelas em producao.

• formatar o JSON.

• enviar as alteracoes.

5.2.2 Conector SQL Server

A organizacao do conector SQL Server consiste em:

• configurar o mecanismo CDC disponibilizado pelo SGBD.

• registar as tabelas em que se pretende capturar alteracoes.

• obter periodicamente as alteracoes registadas pelo SGBD.



• limpar as alteracoes publicadas.


5.2.3 Conector MySQL

A organizacao do conector MySQL consiste em:

• configurar o registo de operacoes binario disponibilizado pelo SGBD.

• garantir que o SGBD esta a persistir as alteracoes ocorridas num ficheiro de registo.

• identificar as tabelas em que se pretende capturar alteracoes.

• ler o ficheiro de registo para obter as alteracoes capturadas.

• aceder a BD em producao para complementar os dados obtidos.



Apesar da equipa nao ter produzido um documento tecnico detalhado sobre o conectorOracle, foi adicionada uma coluna sobre as conversoes deste conector nas tabelas 5.1 e5.2. Assim e possıvel comparar as conversoes realizadas pelo conector desenvolvido pelaequipa e pelos conectores SQL Server e MySQL desenvolvidos no ambito do projetodescrito neste documento.

Tabela 5.1: Conversao entre os tipos das colunas [11]

Tipo Oracle Tipo SQL Server Tipo MySQL Tipo JSONDECIMAL INT INT DECIMALDECIMAL DECIMAL DECIMAL DECIMALNUMBER FLOAT FLOAT UNSUPPORTED

BLOB VARBINARY(MAX) BLOB UNSUPPORTEDCLOB VARCHAR(MAX) TEXT STRING

NCLOB NVARCHAR(MAX) TEXT STRING- DATE DATE TIMESTAMP- TIME TIME TIMESTAMP

TIMESTAMP DATETIME TIMESTAMP TIMESTAMPDATE DATETIME DATETIME TIMESTAMP

5.3 Funcionalidades do sistema

Estas sao as funcionalidades implementadas pelos conectores:

• a detecao de alteracoes nas tabelas.

- Em SQL Server utiliza-se o mecanismo CDC integrado que permite registarem cada linha quais foram as colunas alteradas.


Tabela 5.2: Conversao para JSON suportar caracteres especiais

Carateres especiais Oracle SQL Server MySQL\ \\ \\ \\/ \/ \/” \” \” \”

ASCII(8) \b \bASCII(9) \t \t

ASCII(10) \n \n \nASCII(11) \vASCII(12) \fASCII(13) \r \r \rASCII(92) \

- Apesar disto o conector regista sempre a linha completa que sofreu aalteracao para garantir uma coerencia total dos dados.

- Assim os subscritores do sistema podem definir posteriormente (depois deser realizada a persistencia em Hadoop) qual a frequencia com que pretendem obteros estados anteriores do sistema (snapshots).

- Em MySQL obtem-se os registos do ficheiro de log binario para capturar asalteracoes nas tabelas registadas pelo SGBD.

• a obtencao de alteracoes nas tabelas.

- Obtem-se com cursores em detrimento de tabelas temporarias para melhoraro desempenho.

• a conversao de alteracoes para JSON, dependendo do tipo da coluna como repre-sentado na tabela 5.1.

- Converte-se caracter a caracter para manter a compatibilidade com o SQLServer 2008 (pois a conversao automatica FOR JSON [62] apenas foi introduzidano SQL Server 2016) seguindo as regras descritas na tabela 5.2.

- Convertem-se apenas os dados das colunas compatıveis com numeros deci-mais, sequencias de caracteres ou marcas temporais.

- Utiliza-se CONVERT() [32] e SUBSTRING() [31] para converter as datas(introduzidos no SQL Server 2008) em vez de FORMAT() [10] (introduzido noSQL Server 2012) para:

- manter a compatibilidade com o SQL Server 2008.

- melhorar a performance, pois o FORMAT() utiliza mais recursos da BD.[8]


- apesar do CONVERT() nao suportar uma conversao direta para o formatopretendido.

• a publicacao do JSON formatado num intermediario Kafka.

- Em SQL Server: utilizando a funcionalidade SQLCLR porque oferece maio-res garantias de seguranca aos administradores de BD.

- Este conector nao perde alteracoes mas pode enviar repetidas quando:

- as alteracoes surgem na mesma marca temporal.

- nao e recebida a confirmacao da rececao enviada pelo intermediario Kafka.

- Em MySQL: com recurso a ferramenta cURL [18] no interpretador da linhade comandos.

5.4 Aspetos significativos da implementacao

Os aspetos mais significativos da implementacao estao descritos na documentacaotecnica produzida para auxiliar na instalacao e manutencao dos conectores.

• Manual de instalacao do conector SQL Server: [71]

• Manual de instalacao do conector MySQL: [70]

Capıtulo 6

Testes

Seguidamente e definida a extensao dos testes pretendida e o plano de testes para cadaconector desenvolvido. No plano de testes e fornecida uma descricao detalhada dos testesrealizados para verificar a correta implementacao dos conectores. No final sao apresenta-das algumas conclusoes sobre a cobertura alcancada e os erros detetados pelos testes.

6.1 Plano de testes

Pretende estabelecer-se um plano de testes abrangente aos conectores desenvolvidose ao sistema onde se integram com o objetivo de verificar o funcionamento do trabalhorealizado e aumentar a confianca nas suas capacidades num ambiente proximo aquele emque ira funcionar quando for colocado em producao.

Apenas sao apresentados testes de caixa preta para os procedimentos que tem parametrospois nos outros os testes a realizar sao identicos a alguns testes de caixa branca apresen-tados.

6.1.1 Extensao dos testes unitarios

Os testes unitarios aos procedimentos e funcoes que compoem os conectores SQL Ser-ver (no anexo .1.1) e MySQL (no anexo .1.2) pretendem:

• executar os procedimentos e funcoes com parametros especıficos para que todasas linhas de codigo sejam percorridas de uma forma bem definida e satisfazer orequisito dos caminhos primos [29].

• utilizar um valor representativo para os parametros de forma a que estes cubramtodos os limites das classes de equivalencia e satisfacam o requisito de CoberturaRestrita da Clausula Ativa (Restricted Active Clause Coverage) [2].

6.1.2 Testes unitarios ao conector SQL Server

• Esforco: 1 pessoa.

57

Capıtulo 6. Testes 58

• Duracao: 10 dias.

Os testes realizados ao conector SQL Server sao apresentados no anexo .1.1.

Exemplo de codigo de teste a um procedimento SQL Server

As primeiras linhas comecadas por DECLARE seguido de @nome da variavel e o tipodeclaram todas as variaveis necessarias para realizar o teste.

A linha iniciada por EXEC e o inıcio da chamada ao procedimento, enquanto as linhasseguintes sao a indicacao dos argumentos e a passagem de valores.

As ultimas linhas da chamada da funcao que terminam em OUTPUT sao os argumentosde retorno da funcao.

A figura 6.1 pretende ilustrar as partes comuns a todos os codigos de teste a proce-dimentos SQL Server .1.1 com parametros de entrada e de saıda. A partir deste pontoapenas sera apresentado o codigo de teste especıfico.DECLARE @ColsDeclaration NVARCHAR(MAX),

@ListOfVariables NVARCHAR(MAX),

@ListOfNewVars NVARCHAR(MAX),

@ListOfColNames NVARCHAR(MAX),

@FormatColJSON NVARCHAR(MAX),

@FormatUpdateColJSON NVARCHAR(MAX),

@AnalyseVars NVARCHAR(MAX),

@AnalyseNewVars NVARCHAR(MAX),

@OperationsList NVARCHAR(MAX),

@RowJSON NVARCHAR(MAX);

EXEC usp FetchTableAlterations

@TableName=’Employee’,

@CDCTableRegistryName=’CDCAuxTableRegistry’,

@ColsDeclaration=@ColsDeclaration,

@ListOfVariables=@ListOfVariables,

@ListOfNewVars=@ListOfNewVars,

@ListOfColNames=@ListOfColNames,

@FormatColJSON=@FormatColJSON,

@FormatUpdateColJSON=@FormatUpdateColJSON,

@AnalyseVars=@AnalyseVars,

@AnalyseNewVars=@AnalyseNewVars,

@TS ColumnName=null,

@TS RowVersion=null,

@OperationsList=@OperationsList OUTPUT,

@RowJSON=@RowJSON OUTPUT;


Figura 6.1: Exemplo de Codigo de Teste do conector SQL Server


Descricao dos testes mais complexos ao conector SQL Server

Nos testes unitarios ao conector SQL Server, os mais complexos sao os de caixa pretadevido ao seu numero elevado de parametros e a relacao entre alguns deles:

• no usp FetchTableAlterations 31,33 e necessario agrupar o nome da coluna e aversao das alteracoes pois apenas e possıvel obter o JSON formatado apos umadeterminada versao das alteracoes quando se utilizam ambos.

• no usp MakeJSON 62, 65 e necessario separar os testes que utilizam o nome databela, dos testes que indicam o nome da coluna e a versao das alteracoes paradissociar os casos em que se pretende obter todas as alteracoes de uma determinadatabela ou apenas as que ocorreram apos uma determinada marca temporal.

6.1.3 Testes unitarios ao conector MySQL



Os testes realizados ao conector MySQL sao apresentados no anexo .1.2.

Exemplo de codigo de teste a uma funcao C do conector MySQL

Os testes em C sao compostos por quatro partes principais, a declaracao e inicializacaodas variaveis, a invocacao da funcao a testar e a apresentacao dos resultados do teste.

Na primeira linha declara-se uma sequencia de caracteres para receber o resultado dafuncao.

Na segunda linha inicializa-se um exemplo de uma linha do ficheiro de registo dealteracoes.

Na terceira linha e realizada a chamada a funcao a testar.Na quarta linha e impresso na linha de comandos o resultado do teste.char data[65600];

char *row = "### 2=’Carl Peterson’ /* VARSTRING(150)

meta=150 nullable=1 is null=0 */";

getData(data, row);

printf("data:%s\n, data");

Como o codigo C do conector MySQL e composto por 61 funcoes, apenas serao apre-sentados os testes para as que sao invocadas a partir da funcao principal main.


Descricao dos testes mais complexos ao conector MySQL

Nos testes ao conector MySQL, os mais complexos sao de caixa branca devido a logicatemporal associada:

• no readLastClosedLogFile 20,22 e necessario verificar a coerencia na obtencao deresultados dependendo da marca temporal fornecida.

• no searchForAlterationsInOpenLogFile 46 e necessario verificar se ha um numeroconsideravel de alteracoes detetadas ou se estas dizem respeito a um perıodo tempo-ral alargado e se estas nao incluem alteracoes ja capturadas em obtencoes anteriores.

6.1.4 Extensao dos testes de integracao

Os testes de integracao dos conectores com todo o sistema visam principalmente:

• os pedidos que alteram o estado das BD em producao.

• as operacoes em diversas tabelas e linhas.

• as alteracoes as colunas de tabelas de exemplo das diversas formas possıveis. Assime possıvel validar se sao capturados todos os tipos de alteracoes do modo indicadona tabela 6.1 onde e possıvel observar que o conector Oracle desenvolvido pelaequipa nao regista quaisquer dados antigos devido a restricoes da tecnologia.

• os tipos de colunas SQL Server e MySQL que sao mais representativos para osunicos quatro tipos conhecidos pelo consumidor JSON: Decimal, String, Timestampe Unsupported evitando assim testar varios pseudonimos do mesmo tipo.

• adicionar, alterar e apagar tabelas para testar a abrangencia das capturas de alteracoese as funcoes de registo, atualizacao e cancelamento do registo das tabelas a capturar.

• inserir, alterar e eliminar grandes quantidades de dados para testar a escalabilidadedo sistema com as diferencas entre os varios conectores e verificar se este suportao sistema de larga escala atualmente em producao.

Tabela 6.1: Relacao entre os tipos das operacoes e os dados registados

Tipos de Operacoes Oracle SQL Server MySQLINSERT Regista dados novosUPDATE Regista dados novos Regista dados antigos e novosDELETE Nao regista dados Regista dados antigos


6.1.5 Testes de integracao



Os testes de integracao realizados sao apresentados no anexo .1.3. Estes testes permi-tiram validar o correto funcionamento das interfaces definidas entre os conectores desen-volvidos, as BDs produtoras de dados e o intermediario Kafka.

6.2 Conclusoes dos testes

Os testes unitarios e de integracao realizados permitiram aumentar a confianca nos co-nectores desenvolvidos, validar as interfaces utilizadas e corrigir os 18 erros identificados.Estes erros representam aproximadamente 4,5 erros em cada 1000 linhas de codigo desen-volvido, o que se considerou ser um bom resultado por se aproximar dos valores obtidosquando se desenvolve segundo metodos Cleanroom, inicialmente aplicados pela IBM nofinal da decada de 80 [57].

6.2.1 Cobertura total

• Os testes unitarios de caixa branca foram desenhados para garantir uma coberturade 100% dos caminhos primos [29]. Assim e possıvel encontrar os erros de sintaxeno codigo SQL dinamico porque se testam todos os caminhos de execucao maiscompridos do codigo T-SQL, MySQL e C sem executar os ciclos mais do que umavez por teste.

• Os testes unitarios de caixa preta foram pensados para alcancarem 100% de co-bertura Cobertura Restrita da Clausula Ativa - Restricted Active Clause Coverage(RACC) [2] caso nao se considerem os casos inviaveis. Com a escolha dos valoresde entrada mais representativos e a variacao dos outros argumentos dos procedi-mentos e das funcoes testam-se todas as suas invocacoes mais frequentes.

• Os testes de integracao pretendem verificar o funcionamento do sistema utilizandoos conectores desenvolvidos de modo a providenciar a confianca necessaria para serealizarem testes aos conectores em replicas das BD em producao.

6.2.2 Erros detetados no conector SQL Server

O numero dos testes unitarios que permitiram identificar os erros detetados estao indi-cados junto de cada erro entre parentesis.

Os erros detetados no conector SQL Server com a realizacao dos testes foram:


1. a conversao entre tipos para concatenar sequencias de caracteres(usp GetLastRows:50, 51, 53; usp MakeJSON:68, 70).

2. o comprimento dos tipos das colunas e das variaveis subdimensionado(usp MakeJSON:68,70; usp RegisterTableInCDC:75,76).

3. algumas trocas nas referencias as variaveis, tabelas e procedimentos no codigo SQLdinamico (usp DescribeTable:28,29; usp GetCustomResults:41;usp GetTableColsList:59).

4. a falta de aspas na concatenacao de sequencias de caracteres no SQL dinamico(usp AnalyseStrings:8; usp DescribeTable:28,29; usp GetCustomResults:41;usp GetTableColsList:59).

5. a troca de = por <> e IS NULL por IS NOT NULL nas verificacoes(usp AnalyseStrings:8; usp ConvertJSONType:17,18,19,20).

6. a falta do ORDER BY pelo numero de sequencia das alteracoes registadas numapesquisa com TOP tornava os resultados imprevisıveis (usp MakeJSON:68,70).

7. a concatenacao de sequencias de caracteres com outras sequencias a NULL anu-lam o resultado da concatenacao (usp AnalyseStrings:8; usp ConvertJSONType:17,18,19,20; usp GetLastRows:50,51,53; usp MakeJSON:68,70).

- Em codigo SQL dinamico uma concatenacao que produza NULL consegueanular dezenas de linhas de codigo. Basta que a obtencao de um valor dinamicoproduza NULL para anular todo o codigo SQL dinamico durante a sua execucao(usp DescribeTable:28,29; usp GetCustomResults:41; usp GetTableColsList:59).

8. a falta de um ponto entre o nome do esquema e o nome do procedimento ouda tabela no codigo SQL dinamico (usp DescribeTable:28,29; usp GetCustomRe-sults:41; usp GetTableColsList:59).

9. o bloqueio do envio das alteracoes de uma tabela apos uma determinada marca tem-poral sempre que nao existissem novas alteracoes na tabela do CDC que regista asalteracoes porque os numeros identificadores das linhas alteradas (rowid) estavama ser obtidos desta tabela em vez da tabela original(usp GetLastRows:50,53; usp MakeJSON:70).

10. os erros produzidos por falta de verificacoes dos resultados das consultas e dosvalores de retorno dos procedimentos e funcoes (usp DescribeTable:28,29;usp GetCustomResults:41; usp GetTableColsList:59).

11. a inexistencia das tabelas, procedimentos ou funcoes por execucao noutro esquema(usp FetchTableAlterations:35,36).


12. o acesso bloqueado a algumas tabelas e funcoes da BD por falta de permissoes(usp DescribeTable:28,29; usp GetTableColsList:59;usp FetchTableAlterations:35,36; usp GetLastRows:50,51,53;usp MakeJSON:68,70).

6.2.3 Erros detetados no conector MySQL

O numero dos testes unitarios que permitiram identificar os erros detetados estao indi-cados junto de cada erro entre parentesis.

Os erros detetados no conector MySQL com a realizacao dos testes foram:

1. a nao alocacao de memoria devido a execucao de ”void *malloc(size t size)”[51]com dimensao 0 calculada em tempo de execucao (readLastClosedLogFile:20,22).

2. a falta ocasional de memoria na execucao de ”void *realloc(void *ptr, size t size)”[51]de dimensoes elevadas (readLastClosedLogFile:20,22).

3. os efeitos colaterais de uma ma utilizacao de ”char *strtok(char *str, const char*delim)”[53] pois a sua execucao provoca alteracoes quase imprevisıveis na memoria(readLastClosedLogFile:20,22; updateTimestamp:38,39).

4. a definicao incorreta do comprimento das linhas lidas do ficheiro de log binariousando ”char *fgets(char *s, int size, FILE *stream)”[50] (readConfigFile:6; ge-tLastClosedProcLogFile:13; searchForAlterationsInOpenLogFile:46).

5. as leituras de sequencias de caracteres (readLastClosedLogFile:20,22; searchFo-rAlterationsInOpenLogFile:46) recorrendo a ”int sscanf(const char *str, const char*format, ...)”[52] que:

(a) falhavam devido a utilizacao de ”%s”para ler numeros inteiros onde deveriaser utilizado ”%d”.

(b) produziam valores incorretos por utilizar ”%∗s”para ignorar as sequencias decaracteres erradas.

(c) liam as marcas temporais como uma unica sequencia de caracteres quandoelas surgem no ficheiro de log binario como duas sequencias, data e hora se-paradas por um espaco.

(d) acediam ilegalmente a memoria porque lhes eram disponibilizadas sequenciasde caracteres de dimensoes menores do que os dados lidos em algumas linhasdo ficheiro de log binario.

6. a formatacao do SQL dinamico em tempo de execucao (updateLogPosition: 30,31;updateTimestamp:38,39; searchForAlterationsInOpenLogFile:43; getLastClosed-ProcLogFile:13) que:


(a) nao era concluıda corretamente por faltarem aspas nos nomes dos esquemas etabelas.

(b) nao inseria o caracter de escape ”\”antes dos caracteres especiais [17] o queprovocava problemas durante a execucao no SGBD.

6.3 Discussao

Apos corrigir os erros descritos neste capıtulo, repetiram-se os testes unitarios e deintegracao para verificar se eram obtidos os resultados esperados. Como estes testes naoidentificaram mais erros e no ambiente de desenvolvimento todas as alteracoes demora-ram menos de um minuto para serem disponibilizadas no intermediario Kafka, os conec-tores foram considerados aptos para se realizarem testes de sistema pois cumpriram orequisito de funcionamento quase em tempo real.

Os testes de sistema foram realizados depois da conclusao deste projeto, pelos pro-gramadores mais experientes da equipa, num ambiente de acesso restrito semelhante aode producao em que os sistemas prestam servicos aos clientes. Devido as regras internasda multinacional de telecomunicacoes nao foi possıvel ter acesso a este ambiente pararealizar uma avaliacao de desempenho dos conectores.

Capıtulo 7

Conclusoes

Neste capıtulo sao descritas as tarefas realizadas e os resultados obtidos sao compara-dos com a organizacao de tarefas inicial, com o esforco estimado e com o trabalho identi-ficado. Em seguida e avaliado o trabalho desenvolvido e sao analisadas as diferencas faceas estimativas, o esforco despendido e o decurso do projeto.

7.1 Decomposicao, atribuicao e calendarizacao das tare-fas realizadas

A lista das tarefas realizadas, as duracoes respectivas e as precedencias entre elas estaono diagrama Gantt da figura 3 em anexo.

7.1.1 Medidas do projetoEsforco real despendido

O esforco real despendido pelo autor foi aproximadamente de:

• 8(horas) x 22(dias) x 9(meses) = 1584 horas.

Diferencas em relacao as estimativas

• O esforco real despendido foi aproximadamente o esforco disponıvel identificadona analise.

• O esforco despendido na implementacao foi aproximadamente o dobro do sugeridopelo COCOMO 0.5(pessoas x mes) x 22(dias) = 11 dias vs. 21 dias (diagramaGantt).

Linhas de codigo realizadas

O numero de linhas de codigo desenvolvidas em cada linguagem e:

67

Capıtulo 7. Conclusoes 68

• T-SQL: 1450 linhas.

• MySQL: 91 linhas.

• C: 2472 linhas.

As diferencas em relacao as estimativas sao:

• T-SQL: 165 linhas vs. 1450 linhas = 1285 linhas.

• MySQL e C: 165 linhas vs. 2563 linhas = 2398 linhas.

7.2 Planeado vs. executado

O nıvel de implementacao do conector:

• SQLServer e: 100%.

• MySQL e: 100%.

7.3 Avaliacao post-mortem

7.3.1 Analise global do esforco despendido

Comparando o esforco despendido com as estimativas para:

• A duracao: foi aproximadamente a prevista inicialmente.

• A equipa: manteve-se a dedicacao prevista para o autor (8h em todos os dias uteisdurante 9 meses).

• As linhas de codigo: o numero de linhas superou de forma muito consideravel aestimativa inicial.

• A documentacao: foram realizados adicionalmente os documentos tecnicos paracada conector disponıveis nas ligacoes ja mencionadas.

• As funcionalidades: foi cumprido o funcionamento esperado para os conectoresque tinha sido estabelecido na identificacao de requisitos.


7.3.2 Analise global do decurso do projeto

• O que correu bem: a implementacao dos conectores pois decorreu aproximada-mente como planeado.

• O que correu mal: a analise dos requisitos e o desenho dos diagramas pois foi difıciltermina-los no tempo disponıvel.

• Se comecasse de novo: treinava antecipadamente as linguagens de programacaodos procedimentos e funcoes para as BD.

• O mais interessante: o trabalho produzido pelos conectores que e visıvel nos testesde integracao.

• O menos interessante: a analise do conector Oracle desenvolvido pela equipa.

7.4 Sıntese crıtica do projeto

• Resumidamente o decurso do projeto consistiu em:

- analise e compreensao do trabalho a desenvolver.

- desenho e planeamento da solucao.

- aprendizagem da linguagem T-SQL.

- implementacao do conector SQL Server.

- testes unitarios ao conector SQL Server.

- implementacao do conector MySQL.

- testes unitarios ao conector MySQL.

- testes de integracao ao sistema.

• Noutras circunstancias o projeto deveria ter incluıdo:

- o levantamento de requisitos diretamente com o cliente evitando a utilizacaoda equipa de desenvolvimento como intermediario.

- uma aprendizagem previa da linguagem T-SQL para agilizar o desenvolvi-mento dos conectores.

- o desenvolvimento de um conector de base de dados nao relacional (NoSQL)para aumentar a diversidade das fontes utilizadas na integracao dos dados.

- a utilizacao de um modelo evolutivo de desenvolvimento de software quenecessitava de um cliente com disponibilidade para validar os prototipos dos co-nectores.


- a realizacao dos testes de operacao para a entrada do sistema em producao deforma a completar o plano de testes realizado.

- a implementacao de um sistema consumidor que utilize tecnicas de Data Mi-ning (prospecao de dados) [76] para retirar proveito dos dados integrados.

7.5 Conclusao

Este trabalho foi concluıdo com sucesso produzindo dois conectores de bases de dadosque permitem de forma eficiente e retrocompatıvel capturar, converter e publicar os dadosdos sistemas em producao que utilizam BD SQL Server e MySQL num formato JSONuniforme.

Como e possıvel constatar ao longo deste documento os conectores cumprem asespecificacoes e os requisitos identificados suprindo entao as necessidades existentes.

Durante a analise, o desenho e o desenvolvimento dos conectores existiu um esforcopara os tornar modularizaveis de forma a facilitar a sua manutencao, atualizacao e adicaode novos componentes. Desta forma foram tambem seguidas as premissas do sistemaonde se incluem, que pretende ser uma alternativa estavel ao sistema atualmente em fun-cionamento.

O sistema de integracao de dados esta a funcionar e antes de o colocar em producaoapenas foi necessario realizar testes de sistema com um ambiente semelhante ao de producaopara verificar o seu correto funcionamento.

Adicionalmente foi publicada a comunicacao ”Integracao de Dados de Utilizacao deServicos de Telecomunicacoes”[72] em formato Springer LNCS [1] e apresentado umresumo deste trabalho no grupo BUSIS - Sistemas de Informacao Empresariais 1 dosimposio INForum 2017.

O simposio INForum realizou-se em Aveiro, co-localizado com a exposicao Tech-days 2017 2 e organizado pelo Departamento de Electronica Telecomunicacoes e In-formatica da Universidade de Aveiro 3 com a colaboracao do IEETA 4 e do Institutode Telecomunicacoes 5. As comunicacoes submetidas foram selecionadas e avaliadas porprofessores e investigadores de varias faculdades portuguesas com publicacoes reconhe-cidas por toda a comunidade cientıfica 6. O seu proposito foi a divulgacao do trabalho deinvestigacao e desenvolvimento com relevancia internacional realizado em Portugal nasvarias areas da Informatica.

1INForum2017 - BusIS: Apelo a submissao de artigos de Sistemas de Informacao Empresariais,http://inforum.org.pt/INForum2017/docs/cfp-para-busis

2Techdays :: Building our future - CM Aveiro, http://www.techdays.pt/pt/techdays3Departamento de Eletronica, Telecomunicacoes e Informatica, http://www.ua.pt/deti/page/6194Institute of Electronics and Informatics Engineering of Aveiro,

http://wiki.ieeta.pt/wiki/index.php/Institute of Electronics and Informatics Engineering of Aveiro5Instituto de Telecomunicacoes - Aveiro, https://www.it.pt/ITSites/Index/36Organizacao do INForum2017 - Simposio de Informatica, http://inforum.org.pt/INForum2017/organizacao


Para complementar o trabalho realizado, futuramente poderao ser desenvolvidos co-nectores para outros provedores de BD e podera ser aplicada uma analise posterior aosdados persistidos recorrendo a inteligencia artificial.

Capıtulo 8

Futuros desenvolvimentos

Ha diversos aspetos do sistema abordado neste trabalho que ainda poderao ser desen-volvidos de forma a suprir algumas necessidades da empresa de telecomunicacoes. Osproximos desenvolvimentos consistem em:

• implementar conectores para outros provedores de BD.

• analisar posteriormente os dados persistidos pelo sistema aplicando tecnicas deprospecao de dados [76].

• realizar novos publicadores que permitam ao intermediario Kafka receber dados deBDs NoSQL.

• criar novos subscritores que explorem as potencialidades do sistema para comple-mentar os servicos disponibilizados pela empresa de telecomunicacoes.

73

Capıtulo 8. Futuros desenvolvimentos 74

Bibliografia

[1] Springer Nature Switzerland AG. Lecture notes in computer science LNCS -Springer. https://www.springer.com/gp/computer-science/lncs, 2018. Consultadoem 12 de fevereiro de 2018. https://web.archive.org/web/20180730194807/https://www.springer.com/gp/computer-science/lncs.

[2] Paul Ammann, Offutt Jeff, and Huang Hong. Coverage criteria for logicalexpressions, chapter 2.1, definition 5(iii). Software Reliability Engineering, 2003.ISSRE 2003. 14th International Symposium on. IEEE, 2003.

[3] Oracle Corporation and/or its affiliates. MySQL :: MySQL 5.6 reference manual ::4.6.8 mysqlbinlog — utility for processing binary log files.https://dev.mysql.com/doc/refman/5.6/en/mysqlbinlog.html. Consultado em 14 defevereiro de 2018. https://web.archive.org/web/20170712043305/https://dev.mysql.com/doc/refman/5.6/en/mysqlbinlog.html.

[4] Oracle Corporation and/or its affiliates. MySQL :: MySQL 5.7 reference manual ::13.16.2 functions that create JSON values.https://dev.mysql.com/doc/refman/5.7/en/json-creation-functions.html. Consultadoem 27 de abril de 2017. https://web.archive.org/web/20170403212104/https://dev.mysql.com/doc/refman/5.7/en/json-creation-functions.html.

[5] Oracle Corporation and/or its affiliates. MySQL :: MySQL internals manual :: 20.1binary log overview.https://dev.mysql.com/doc/internals/en/binary-log-overview.html. Consultado em27 de abril de 2017. https://web.archive.org/web/20170515210549/https://dev.mysql.com/doc/internals/en/binary-log-overview.html.

[6] Oracle Corporation and/or its affiliates. MySQL :: MySQL internals manual ::20.10 row-based binary logging.https://dev.mysql.com/doc/internals/en/row-based-binary-logging.html. Consultadoem 27 de abril de 2017. https://web.archive.org/web/20170515210356/https://dev.mysql.com/doc/internals/en/row-based-binary-logging.html.

75

https://web.archive.org/web/20180730194807/https://www.springer.com/gp/computer-science/lncs

https://web.archive.org/web/20180730194807/https://www.springer.com/gp/computer-science/lncs

https://web.archive.org/web/20170712043305/https://dev.mysql.com/doc/refman/5.6/en/mysqlbinlog.html

https://web.archive.org/web/20170712043305/https://dev.mysql.com/doc/refman/5.6/en/mysqlbinlog.html

https://web.archive.org/web/20170403212104/https://dev.mysql.com/doc/refman/5.7/en/json-creation-functions.html

https://web.archive.org/web/20170403212104/https://dev.mysql.com/doc/refman/5.7/en/json-creation-functions.html

https://web.archive.org/web/20170515210549/https://dev.mysql.com/doc/internals/en/binary-log-overview.html

https://web.archive.org/web/20170515210549/https://dev.mysql.com/doc/internals/en/binary-log-overview.html

https://web.archive.org/web/20170515210356/https://dev.mysql.com/doc/internals/en/row-based-binary-logging.html

https://web.archive.org/web/20170515210356/https://dev.mysql.com/doc/internals/en/row-based-binary-logging.html

Bibliografia 76

[7] Techdays CM Aveiro. Techdays :: Building our future.http://www.techdays.pt/pt/techdays. Consultado em 12 de fevereiro de 2018.https://web.archive.org/web/20180730201615/http://www.techdays.pt/pt/techdays.

[8] Aaron. Bertrand. Format() is nice and all, but... - sqlperformance.com.https://sqlperformance.com/2015/06/t-sql-queries/format-is-nice-and-all-but, junho2015. Consultado em 4 de abril de 2017.https://web.archive.org/web/20170516135926/https://sqlperformance.com/2015/06/t-sql-queries/format-is-nice-and-all-but.

[9] Rick Byham and Craig Guyer. datetime2 (Transact-SQL) — Microsoft Docs.https://docs.microsoft.com/en-us/sql/t-sql/data-types/datetime2-transact-sql, junho2016. Consultado em 6 de junho 2017.https://web.archive.org/web/20170825201216/https://docs.microsoft.com/en-us/sql/t-sql/data-types/datetime2-transact-sql.

[10] Rick Byham and Craig Guyer. Format (Transact-SQL) — Microsoft Docs.https://docs.microsoft.com/en-us/sql/t-sql/functions/format-transact-sql, junho2016. Consultado em 27 de abril de 2017.https://web.archive.org/web/20170819152257/https://docs.microsoft.com/en-us/sql/t-sql/functions/format-transact-sql.

[11] Rick Byham and Craig Guyer. Data type mapping for Oracle publishers —Microsoft Docs. https://docs.microsoft.com/en-us/sql/relational-databases/replication/non-sql/data-type-mapping-for-oracle-publishers, marco2017. Consultado em 4 de abril de 2017. https://web.archive.org/web/20170414153713/https://docs.microsoft.com/en-us/sql/relational-databases/replication/non-sql/data-type-mapping-for-oracle-publishers.

[12] Rick Byham, Gene Milener, and Craig Guyer. Create trigger (Transact-SQL) —Microsoft Docs.https://docs.microsoft.com/en-us/sql/t-sql/statements/create-trigger-transact-sql,abril 2017. Consultado em 27 de abril de 2017.https://web.archive.org/web/20170919143400/https://docs.microsoft.com/en-us/sql/t-sql/statements/create-trigger-transact-sql.

[13] Rick Byham, Gene Milener, and Craig Guyer. Create type (Transact-SQL) —Microsoft Docs.https://docs.microsoft.com/en-us/sql/t-sql/statements/create-type-transact-sql, abril2017. Consultado em 4 de abril de 2017.https://web.archive.org/web/20170529163105/https://docs.microsoft.com/en-us/sql/t-sql/statements/create-type-transact-sql.

https://web.archive.org/web/20180730201615/http://www.techdays.pt/pt/techdays

https://web.archive.org/web/20170516135926/https://sqlperformance.com/2015/06/t-sql-queries/format-is-nice-and-all-but

https://web.archive.org/web/20170516135926/https://sqlperformance.com/2015/06/t-sql-queries/format-is-nice-and-all-but

https://web.archive.org/web/20170825201216/https://docs.microsoft.com/en-us/sql/t-sql/data-types/datetime2-transact-sql

https://web.archive.org/web/20170825201216/https://docs.microsoft.com/en-us/sql/t-sql/data-types/datetime2-transact-sql

https://web.archive.org/web/20170819152257/https://docs.microsoft.com/en-us/sql/t-sql/functions/format-transact-sql

https://web.archive.org/web/20170819152257/https://docs.microsoft.com/en-us/sql/t-sql/functions/format-transact-sql

https://web.archive.org/web/20170414153713/https://docs.microsoft.com/en-us/sql/relational-databases/replication/non-sql/data-type-mapping-for-oracle-publishers



https://web.archive.org/web/20170919143400/https://docs.microsoft.com/en-us/sql/t-sql/statements/create-trigger-transact-sql

https://web.archive.org/web/20170919143400/https://docs.microsoft.com/en-us/sql/t-sql/statements/create-trigger-transact-sql

https://web.archive.org/web/20170529163105/https://docs.microsoft.com/en-us/sql/t-sql/statements/create-type-transact-sql

https://web.archive.org/web/20170529163105/https://docs.microsoft.com/en-us/sql/t-sql/statements/create-type-transact-sql

Bibliografia 77

[14] Debezium Community. Debezium. http://debezium.io/. Consultado em 13 dejaneiro de 2017. https://web.archive.org/web/20180702081249/http://debezium.io/.

[15] Hitachi Vantara Corporation. Pentaho data integration - accelerate data pipeline —Hitachi Vantara. https://www.hitachivantara.com/en-us/products/big-data-integration-analytics/pentaho-data-integration.html. Consultado em 14 de fevereirode 2018. https://web.archive.org/web/20180731200612/https://www.hitachivantara.com/en-us/products/big-data-integration-analytics/pentaho-data-integration.html.

[16] IBM Corporation. IBM knowledge center - change data capture (CDC) replication.https://www.ibm.com/support/knowledgecenter/en/SSTRGZ -10.2.0/com.ibm.cdcdoc.homepage cdc technology.doc/ic-homepage-cdc.html.Consultado em 14 de fevereiro de 2018.

[17] Oracle Corporation. Mysql :: Mysql 5.7 reference manual :: 9.1.1 string literals.https://dev.mysql.com/doc/refman/5.7/en/string-literals.html. Consultado em 14 defevereiro de 2018. https://web.archive.org/web/20170712213023/https://dev.mysql.com/doc/refman/5.7/en/string-literals.html.

[18] cURL. cURLl - how to use. https://curl.haxx.se/docs/manpage.html. Consultadoem 20 de setembro de 2017.

[19] dan da. GitHub - dan-da/cdc audit: change data capture via audit tables andtriggers for mysql. https://github.com/dan-da/cdc audit, dezembro 2015.Consultado em 15 de setembro de 2017.https://web.archive.org/web/20171022162238/https://github.com/dan-da/cdc audit.

[20] Arnold Daniels. GitHub - mysqludf/lib mysqludf json: A UDF library of functionsto map relational data to the JSON format.https://github.com/mysqludf/lib mysqludf json, fevereiro 2013. Consultado em 15de setembro de 2017. https://web.archive.org/web/20171022170243/https://github.com/mysqludf/lib mysqludf json.

[21] Universidade de Aveiro. Departamento de eletronica, telecomunicacoes einformatica - departamento. http://www.ua.pt/deti/page/619. Consultado em 12 defevereiro de 2018.https://web.archive.org/web/20180730201655/http://www.ua.pt/deti/page/619.

[22] Universidade de Aveiro. Institute of electronics and informatics engineering ofaveiro - ieeta. http://wiki.ieeta.pt/wiki/index.php/Institute of Electronics and -Informatics Engineering of Aveiro. Consultado em 12 de fevereiro de 2018.https://web.archive.org/web/20180730201800/http://wiki.ieeta.pt/wiki/index.php/Institute of Electronics and Informatics Engineering of Aveiro.

https://web.archive.org/web/20180702081249/http://debezium.io/

https://web.archive.org/web/20180731200612/https://www.hitachivantara.com/en-us/products/big-data-integration-analytics/pentaho-data-integration.html

https://web.archive.org/web/20180731200612/https://www.hitachivantara.com/en-us/products/big-data-integration-analytics/pentaho-data-integration.html

https://web.archive.org/web/20170712213023/https://dev.mysql.com/doc/refman/5.7/en/string-literals.html

https://web.archive.org/web/20170712213023/https://dev.mysql.com/doc/refman/5.7/en/string-literals.html

https://web.archive.org/web/20171022162238/https://github.com/dan-da/cdc_audit

https://web.archive.org/web/20171022170243/https://github.com/mysqludf/lib_mysqludf_json

https://web.archive.org/web/20171022170243/https://github.com/mysqludf/lib_mysqludf_json

https://web.archive.org/web/20180730201655/http://www.ua.pt/deti/page/619

https://web.archive.org/web/20180730201800/http://wiki.ieeta.pt/wiki/index.php/Institute_of_Electronics_and_Informatics_Engineering_of_Aveiro

https://web.archive.org/web/20180730201800/http://wiki.ieeta.pt/wiki/index.php/Institute_of_Electronics_and_Informatics_Engineering_of_Aveiro

Bibliografia 78

[23] INForum Simposio de Informatica. BusIS 2017: Apelo a submissao de artigos desistemas de informacao empresariais.http://inforum.org.pt/INForum2017/docs/cfp-para-busis, outubro 2017. Consultadoem 12 de fevereiro de 2018. https://web.archive.org/web/20180731221213/http://inforum.org.pt/INForum2017/docs/cfp-para-busis.

[24] INForum Simposio de Informatica. Organizacao — INForum2017.http://inforum.org.pt/INForum2017/organizacao, outubro 2017. Consultado em 12de fevereiro de 2018. https://web.archive.org/web/20171109031617/http://inforum.org.pt:80/INForum2017/organizacao.

[25] Instituto de Telecomunicacoes. IT – Aveiro. https://www.it.pt/ITSites/Index/3.Consultado em 12 de fevereiro de 2018.https://web.archive.org/web/20180730201756/https://www.it.pt/ITSites/Index/3.

[26] Grupos do Google Confluent Plataform. Is there a SQL Server CDC connector forKafka connect? - grupos do google.https://groups.google.com/forum/m/#!topic/confluent-platform/UXTojFZoZfk,junho e julho 2016. Consultado em 13 de janeiro de 2017.

[27] Grupos do Google Confluent Plataform. Kafka connect - is this the expectedbehavior? - grupos do google.https://groups.google.com/forum/m/#!msg/confluent-platform/hkyDslGym9g/zPSqYAvKAgAJ, julho 2016. Consultado em 13 dejaneiro de 2017.

[28] Grupos do Google Confluent Plataform. Kafka connect: connecting JDBC sourceusing SQL Server - grupos do google.https://groups.google.com/forum/m/#!topic/confluent-platform/niQUd4SYwCE,dezembro 2016. Consultado em 13 de janeiro de 2017.

[29] A. Dwarakanath and A. Jankiti. Minimum number of test paths for prime path andother structural coverage criteria, Related Work. In: Merayo M.G., de Oca E.M.(eds) Testing Software and Systems. ICTSS 2014. Lecture Notes in ComputerScience, vol 8763. Springer, Berlin, Heidelberg, 2014.

[30] Telefonaktiebolaget LM Ericsson. Communication services - ericsson.https://www.ericsson.com/ourportfolio/digital-services-solution-areas/communication-services. Consultado em 14 de fevereiro de 2018.https://web.archive.org/web/20180730203455/https://www.ericsson.com/ourportfolio/digital-services-solution-areas/communication-services.

https://web.archive.org/web/20180731221213/http://inforum.org.pt/INForum2017/docs/cfp-para-busis

https://web.archive.org/web/20180731221213/http://inforum.org.pt/INForum2017/docs/cfp-para-busis

https://web.archive.org/web/20171109031617/http://inforum.org.pt:80/INForum2017/organizacao

https://web.archive.org/web/20171109031617/http://inforum.org.pt:80/INForum2017/organizacao

https://web.archive.org/web/20180730201756/https://www.it.pt/ITSites/Index/3

https://web.archive.org/web/20180730203455/https://www.ericsson.com/ourportfolio/digital-services-solution-areas/communication-services

https://web.archive.org/web/20180730203455/https://www.ericsson.com/ourportfolio/digital-services-solution-areas/communication-services

Bibliografia 79

[31] Craig Guyer et al. Substring (Transact-SQL) — Microsoft Docs.https://docs.microsoft.com/en-us/sql/t-sql/functions/substring-transact-sql, outubro2016. Consultado em 27 de abril de 2017.https://web.archive.org/web/20180801214457/https://docs.microsoft.com/en-us/sql/t-sql/functions/substring-transact-sql?view=sql-server-2017.

[32] Masha Thomas et al. Cast and convert (Transact-SQL) — Microsoft Docs.https://docs.microsoft.com/en-us/sql/t-sql/functions/cast-and-convert-transact-sql,abril 2018. Consultado em 14 de fevereiro de 2018.https://web.archive.org/web/20180724091241/https://docs.microsoft.com/en-us/sql/t-sql/functions/cast-and-convert-transact-sql?view=sql-server-2017.

[33] Patrick Eugster, Rachid Guerraoui, and Joe Sventek. Distributed asynchronouscollections: Abstractions for publish/subscribe interaction, Abstract. ECOOP2000—Object-Oriented Programming : 252-276., 2000.

[34] GitHub. Github - debezium/debezium: Change data capture for a variety ofdatabases. https://github.com/debezium/debezium. Consultado em 13 de janeiro de2017. https://web.archive.org/web/20170208100506/https://github.com/debezium/debezium.

[35] GitHub. Github - jpalomo/kafka-connect-mssqlserver-cdc.https://github.com/jpalomo/kafka-connect-mssqlserver-cdc. Consultado em 15 desetembro de 2017. https://web.archive.org/web/20171015175613/https://github.com/jpalomo/kafka-connect-mssqlserver-cdc.

[36] GitHub. Github - no9/sqlcdcstream: A stream of SQL Server change events.https://github.com/No9/sqlcdcstream. Consultado em 16 de janeiro de 2017. https://web.archive.org/web/20170130193156/https://github.com/No9/sqlcdcstream.

[37] GitHub. Github - pyr/recordbus: recordbus: MySQL binlog to Apache Kafka.https://github.com/pyr/recordbus. Consultado em 13 de janeiro de 2017.https://web.archive.org/web/20170130193306/https://github.com/pyr/recordbus.

[38] GitHub. Github - shyiko/mysql-binlog-connector-java: MySQL binary logconnector. https://github.com/shyiko/mysql-binlog-connector-java. Consultado em13 de janeiro de 2017. https://web.archive.org/web/20160131195334/https://github.com/shyiko/mysql-binlog-connector-java.

[39] GitHub. Github - yelp/mysql-streamer: MySQLStreamer is a database change datacapture and publish system. https://github.com/Yelp/mysql streamer. Consultadoem 13 de janeiro de 2017. https://web.archive.org/web/20180702081255/https://github.com/Yelp/mysql streamer.

https://web.archive.org/web/20180801214457/https://docs.microsoft.com/en-us/sql/t-sql/functions/substring-transact-sql?view=sql-server-2017

https://web.archive.org/web/20180801214457/https://docs.microsoft.com/en-us/sql/t-sql/functions/substring-transact-sql?view=sql-server-2017

https://web.archive.org/web/20180724091241/https://docs.microsoft.com/en-us/sql/t-sql/functions/cast-and-convert-transact-sql?view=sql-server-2017

https://web.archive.org/web/20180724091241/https://docs.microsoft.com/en-us/sql/t-sql/functions/cast-and-convert-transact-sql?view=sql-server-2017

https://web.archive.org/web/20170208100506/https://github.com/debezium/debezium

https://web.archive.org/web/20170208100506/https://github.com/debezium/debezium

https://web.archive.org/web/20171015175613/https://github.com/jpalomo/kafka-connect-mssqlserver-cdc

https://web.archive.org/web/20171015175613/https://github.com/jpalomo/kafka-connect-mssqlserver-cdc

https://web.archive.org/web/20170130193156/https://github.com/No9/sqlcdcstream

https://web.archive.org/web/20170130193156/https://github.com/No9/sqlcdcstream

https://web.archive.org/web/20170130193306/https://github.com/pyr/recordbus

https://web.archive.org/web/20160131195334/https://github.com/shyiko/mysql-binlog-connector-java

https://web.archive.org/web/20160131195334/https://github.com/shyiko/mysql-binlog-connector-java

https://web.archive.org/web/20180702081255/https://github.com/Yelp/mysql_streamer

https://web.archive.org/web/20180702081255/https://github.com/Yelp/mysql_streamer

Bibliografia 80

[40] GitHub. Github - zendesk/maxwell - maxwell’s daemon, a mysql-to-json kafkaproducer. https://github.com/zendesk/maxwell. Consultado em 13 de janeiro de2017.https://web.archive.org/web/20170130193800/https://github.com/zendesk/maxwell.

[41] GitHub. Github - mardambey/mypipe: MySQL binary log consumer with theability to act on changed rows and publish changes to different systems withemphasis on Apache Kafka. https://github.com/mardambey/mypipe, julho 2016.Consultado em 13 de janeiro de 2017. https://web.archive.org/web/20170208100545/https://github.com/mardambey/mypipe.

[42] GitHub. Github - vmware/tungsten-replicator: Tungsten replicator.https://github.com/vmware/tungsten-replicator, fevereiro 2016. Consultado em 13de janeiro de 2017. https://web.archive.org/web/20170324175232/https://github.com/vmware/tungsten-replicator.

[43] GitHub. Github - whitesock/open-replicator: Open replicator is a high performanceMySQL binlog parser written in java. it unfolds the possibilities that you can parse,filter and broadcast the binlog events in a real time manner.https://github.com/whitesock/open-replicator, janeiro 2016. Consultado em 13 dejaneiro de 2017. https://web.archive.org/web/20170208100542/https://github.com/whitesock/open-replicator.

[44] Jennifer Hubbard, Craig Guyer, and Rick Byham. Overview of CLR integration —Microsoft Docs. https://docs.microsoft.com/en-us/sql/relational-databases/clr-integration/clr-integration-overview, abril 2017. Consultado em 27 de abril de2017. https://web.archive.org/web/20170515204404/https://docs.microsoft.com/en-us/sql/relational-databases/clr-integration/clr-integration-overview.

[45] Bray T. Google Inc. RFC 7159 - the javascript object notation (json) datainterchange format. https://tools.ietf.org/html/rfc7159, marco 2014. Consultado em14 de fevereiro de 2018.https://web.archive.org/web/20170921150200/https://tools.ietf.org/html/rfc7159.

[46] CGI Group Inc. Customer service and billing: Telco and media - CGI UK.https://www.cgi-group.co.uk/solutions/mass-data-billing/telecommunications.Consultado em 14 de fevereiro de 2018.https://web.archive.org/web/20180730203957/https://www.cgi-group.co.uk/solutions/mass-data-billing/telecommunications.

[47] Cisco Systems Inc. Managed services - cisco.https://www.cisco.com/c/en/us/services/managed.html. Consultado em 14 de

https://web.archive.org/web/20170130193800/https://github.com/zendesk/maxwell

https://web.archive.org/web/20170208100545/https://github.com/mardambey/mypipe

https://web.archive.org/web/20170208100545/https://github.com/mardambey/mypipe

https://web.archive.org/web/20170324175232/https://github.com/vmware/tungsten-replicator

https://web.archive.org/web/20170324175232/https://github.com/vmware/tungsten-replicator

https://web.archive.org/web/20170208100542/https://github.com/whitesock/open-replicator

https://web.archive.org/web/20170208100542/https://github.com/whitesock/open-replicator

https://web.archive.org/web/20170515204404/https://docs.microsoft.com/en-us/sql/relational-databases/clr-integration/clr-integration-overview

https://web.archive.org/web/20170515204404/https://docs.microsoft.com/en-us/sql/relational-databases/clr-integration/clr-integration-overview

https://web.archive.org/web/20170921150200/https://tools.ietf.org/html/rfc7159

https://web.archive.org/web/20180730203957/https://www.cgi-group.co.uk/solutions/mass-data-billing/telecommunications

https://web.archive.org/web/20180730203957/https://www.cgi-group.co.uk/solutions/mass-data-billing/telecommunications

Bibliografia 81

fevereiro de 2018. https://web.archive.org/web/20180730203711/https://www.cisco.com/c/en/us/services/managed.html.

[48] Informatica. Informatica connector toolkit: MySQL connector.https://marketplace.informatica.com/solutions/informatica connector toolkit -mysql connector. Consultado em 14 de fevereiro de 2018.https://web.archive.org/web/20180731195800/https://marketplace.informatica.com/solutions/informatica connector toolkit mysql connector.

[49] Informatica. PowerCenter: Enterprise data integration platform — Informatica US.https://www.informatica.com/products/data-integration/powercenter.html#fbid=6LJZThXQPSG. Consultado em 14 defevereiro de 2018. https://web.archive.org/web/20180731195234/https://www.informatica.com/products/data-integration/powercenter.html#fbid=pFqnR2QgLzd.

[50] Michael Kerrisk. fgetc(3) - linux manual page.http://man7.org/linux/man-pages/man3/fgetc.3.html. Consultado em 14 defevereiro de 2018. https://web.archive.org/web/20171228005636/http://man7.org:80/linux/man-pages/man3/fgetc.3.html.

[51] Michael Kerrisk. malloc(3) - linux manual page.http://man7.org/linux/man-pages/man3/realloc.3.html. Consultado em 14 defevereiro de 2018. https://web.archive.org/web/20180103165408/http://man7.org:80/linux/man-pages/man3/realloc.3.html.

[52] Michael Kerrisk. scanf(3) - linux manual page.http://man7.org/linux/man-pages/man3/scanf.3.html. Consultado em 14 defevereiro de 2018. https://web.archive.org/web/20171229065551/http://man7.org:80/linux/man-pages/man3/scanf.3.html.

[53] Michael Kerrisk. strtok(3) - linux manual page.http://man7.org/linux/man-pages/man3/strtok r.3.html. Consultado em 14 defevereiro de 2018. https://web.archive.org/web/20171220104840/http://man7.org:80/linux/man-pages/man3/strtok r.3.html.

[54] G. Klyne and C. Newman. RFC3339 - date and time on the internet: Timestamps.https://tools.ietf.org/html/rfc3339, julho 2002. Consultado em 4 de abril de 2017.https://web.archive.org/web/20170327174400/https://tools.ietf.org/html/rfc3339.

[55] Markus Kuhn. A summary of the international standard date and time notation.https://www.cl.cam.ac.uk/ mgk25/iso-time.html, junho 2004. Consultado em 27 deabril de 2017. https://web.archive.org/web/20170405194123/http://www.cl.cam.ac.uk/∼mgk25/iso-time.html.

https://web.archive.org/web/20180730203711/https://www.cisco.com/c/en/us/services/managed.html

https://web.archive.org/web/20180730203711/https://www.cisco.com/c/en/us/services/managed.html

https://web.archive.org/web/20180731195800/https://marketplace.informatica.com/solutions/informatica_connector_toolkit_mysql_connector

https://web.archive.org/web/20180731195800/https://marketplace.informatica.com/solutions/informatica_connector_toolkit_mysql_connector

https://web.archive.org/web/20180731195234/https://www.informatica.com/products/data-integration/powercenter.html#fbid=pFqnR2QgLzd

https://web.archive.org/web/20180731195234/https://www.informatica.com/products/data-integration/powercenter.html#fbid=pFqnR2QgLzd

https://web.archive.org/web/20171228005636/http://man7.org:80/linux/man-pages/man3/fgetc.3.html

https://web.archive.org/web/20171228005636/http://man7.org:80/linux/man-pages/man3/fgetc.3.html

https://web.archive.org/web/20180103165408/http://man7.org:80/linux/man-pages/man3/realloc.3.html

https://web.archive.org/web/20180103165408/http://man7.org:80/linux/man-pages/man3/realloc.3.html

https://web.archive.org/web/20171229065551/http://man7.org:80/linux/man-pages/man3/scanf.3.html

https://web.archive.org/web/20171229065551/http://man7.org:80/linux/man-pages/man3/scanf.3.html

https://web.archive.org/web/20171220104840/http://man7.org:80/linux/man-pages/man3/strtok_r.3.html

https://web.archive.org/web/20171220104840/http://man7.org:80/linux/man-pages/man3/strtok_r.3.html

https://web.archive.org/web/20170327174400/https://tools.ietf.org/html/rfc3339

https://web.archive.org/web/20170405194123/http://www.cl.cam.ac.uk/~mgk25/iso-time.html

https://web.archive.org/web/20170405194123/http://www.cl.cam.ac.uk/~mgk25/iso-time.html

Bibliografia 82

[56] Tom Kyte. Ask Tom: The trouble with triggers.http://www.oracle.com/technetwork/testcontent/o58asktom-101055.html, setembro2008. Consultado em 15 de setembro de 2017.https://web.archive.org/web/20170524163617/http://www.oracle.com:80/technetwork/testcontent/o58asktom-101055.html.

[57] Richard C. Linger. Cleanroom software engineering for zero-defect software.Proceedings of the 15th international conference on Software Engineering. IEEEComputer Society Press, p.2-13, maio 1993.

[58] Nikolay Manchev. IBM DataStage ODBC connectivity to MySQL communityedition databases.https://www-01.ibm.com/support/docview.wss?uid=swg21458603. Consultado em14 de fevereiro de 2018. https://web.archive.org/web/20180731200105/https://www-01.ibm.com/support/docview.wss?uid=swg21458603.

[59] Nikolay Manchev. Replicating transactions between Microsoft SQL Server andOracle database using Oracle GoldenGate.http://www.oracle.com/technetwork/articles/datawarehouse/oracle-sqlserver-goldengate-460262.html, agosto 2011. Consultado em 14 de fevereiro de 2018.https://web.archive.org/web/20180104034256/http://www.oracle.com:80/technetwork/articles/datawarehouse/oracle-sqlserver-goldengate-460262.html.

[60] Jovan Popovic (MSFT). JSON in SQL Server 2016: Part 4 of 4 — SQL Serverblog. https://blogs.technet.microsoft.com/dataplatforminsider/2016/01/08/json-in-sql-server-2016-part-4-of-4/, janeiro 2016. Consultado em 13 de janeiro de 2017.https://web.archive.org/web/20180709181947/https://cloudblogs.microsoft.com/sqlserver/2016/01/08/json-in-sql-server-2016-part-4-of-4/.

[61] Microsoft Developer Network. About change data capture (SQL Server).https://msdn.microsoft.com/en-us/library/cc645937.aspx. Consultado em 13 dejaneiro de 2017. https://web.archive.org/web/20160509053246/https://msdn.microsoft.com/en-us/library/cc645937.aspx.

[62] Microsoft Developer Network. Format query results as JSON with FOR JSON(SQL Server). https://msdn.microsoft.com/en-us/library/dn921882.aspx.Consultado em 13 de janeiro de 2017.https://web.archive.org/web/20170221152948/https://msdn.microsoft.com/en-us/library/dn921882.aspx.

[63] Microsoft Developer Network. Schedule a job.https://msdn.microsoft.com/en-us/library/ms191439.aspx. Consultado em 13 de

https://web.archive.org/web/20170524163617/http://www.oracle.com:80/technetwork/testcontent/o58asktom-101055.html

https://web.archive.org/web/20170524163617/http://www.oracle.com:80/technetwork/testcontent/o58asktom-101055.html

https://web.archive.org/web/20180731200105/https://www-01.ibm.com/support/docview.wss?uid=swg21458603

https://web.archive.org/web/20180731200105/https://www-01.ibm.com/support/docview.wss?uid=swg21458603

https://web.archive.org/web/20180104034256/http://www.oracle.com:80/technetwork/articles/datawarehouse/oracle-sqlserver-goldengate-460262.html

https://web.archive.org/web/20180104034256/http://www.oracle.com:80/technetwork/articles/datawarehouse/oracle-sqlserver-goldengate-460262.html

https://web.archive.org/web/20180709181947/https://cloudblogs.microsoft.com/sqlserver/2016/01/08/json-in-sql-server-2016-part-4-of-4/

https://web.archive.org/web/20180709181947/https://cloudblogs.microsoft.com/sqlserver/2016/01/08/json-in-sql-server-2016-part-4-of-4/

https://web.archive.org/web/20160509053246/https://msdn.microsoft.com/en-us/library/cc645937.aspx

https://web.archive.org/web/20160509053246/https://msdn.microsoft.com/en-us/library/cc645937.aspx

https://web.archive.org/web/20170221152948/https://msdn.microsoft.com/en-us/library/dn921882.aspx

https://web.archive.org/web/20170221152948/https://msdn.microsoft.com/en-us/library/dn921882.aspx

Bibliografia 83

janeiro de 2017. https://web.archive.org/web/20160911120334/https://msdn.microsoft.com/en-us/library/ms191439.aspx.

[64] Microsoft Developer Network. xp cmdshell (Transact-SQL).https://msdn.microsoft.com/en-us/library/ms175046.aspx. Consultado em 13 dejaneiro de 2017. https://web.archive.org/web/20170302100539/https://msdn.microsoft.com/en-us/library/ms175046.aspx.

[65] Oracle. MySQL :: MySQL 5.6 reference manual :: 17.1.3 replication with globaltransaction identifiers.https://dev.mysql.com/doc/refman/5.6/en/replication-gtids.html. Consultado em 15de setembro de 2017. https://web.archive.org/web/20171022162315/https://dev.mysql.com/doc/refman/5.6/en/replication-gtids.html.

[66] Ben Osheroff. Introducing maxwell, a mysql-to-kafka binlog processor -zengineering blog - zendesk developer portal.https://developer.zendesk.com/blog/introducing-maxwell-a-mysql-to-kafka-binlog-processor. Consultado em 13 de janeiro de 2017.https://web.archive.org/web/20170208100334/https://developer.zendesk.com/blog/introducing-maxwell-a-mysql-to-kafka-binlog-processor.

[67] Wolfgang Pree, Marcus Fontoura, and Bernhard Rumpe. Product line annotationswith UML-F. https://link.springer.com/chapter/10.1007/3-540-45652-X 12, julho2002. Consultado em 6 de junho 2017.https://web.archive.org/web/20180614000619/https://link.springer.com/chapter/10.1007%2F3-540-45652-X 12.

[68] SAP SE. MDM change tracker application guide - SAP help portal.https://help.sap.com/viewer/691b78a1277346c995c240dd6ba34f6c/7.1.18/en-US/49a42bc834de1b93e10000000a42189b.html. Consultado em 14 de fevereiro de2018.

[69] Prem Santosh Udaya Shankar. Streaming MySQL tables in real-time to Kafka.https://engineeringblog.yelp.com/2016/08/streaming-mysql-tables-in-real-time-to-kafka.html, agosto 2016. Consultado em 13 de janeiro de 2017.https://web.archive.org/web/20170331013956/https://engineeringblog.yelp.com/2016/08/streaming-mysql-tables-in-real-time-to-kafka.html.

[70] I. Silva and C. Teixeira. Manual de instalacao do conector MySQL v5.7.6 para ointermediario Kafka. http://repositorio.ul.pt/handle/10451/31159, novembro 2017.Consultado em 12 de fevereiro de 2018.https://web.archive.org/web/20180709184111/http://repositorio.ul.pt/handle/10451/31159.

https://web.archive.org/web/20160911120334/https://msdn.microsoft.com/en-us/library/ms191439.aspx




https://web.archive.org/web/20171022162315/https://dev.mysql.com/doc/refman/5.6/en/replication-gtids.html

https://web.archive.org/web/20171022162315/https://dev.mysql.com/doc/refman/5.6/en/replication-gtids.html

https://web.archive.org/web/20170208100334/https://developer.zendesk.com/blog/introducing-maxwell-a-mysql-to-kafka-binlog-processor

https://web.archive.org/web/20170208100334/https://developer.zendesk.com/blog/introducing-maxwell-a-mysql-to-kafka-binlog-processor

https://web.archive.org/web/20180614000619/https://link.springer.com/chapter/10.1007%2F3-540-45652-X_12

https://web.archive.org/web/20180614000619/https://link.springer.com/chapter/10.1007%2F3-540-45652-X_12

https://web.archive.org/web/20170331013956/https://engineeringblog.yelp.com/2016/08/streaming-mysql-tables-in-real-time-to-kafka.html

https://web.archive.org/web/20170331013956/https://engineeringblog.yelp.com/2016/08/streaming-mysql-tables-in-real-time-to-kafka.html

https://web.archive.org/web/20180709184111/http://repositorio.ul.pt/handle/10451/31159


Bibliografia 84

[71] I. Silva and C. Teixeira. Manual de instalacao do conector SQL Server 2008 para ointermediario Kafka. http://repositorio.ul.pt/handle/10451/31160, novembro 2017.Consultado em 12 de fevereiro de 2018.https://web.archive.org/web/20180709184614/http://repositorio.ul.pt/handle/10451/31160.

[72] Ivo Silva, Carlos Teixeira, and Ana Guimaraes. Integracao de dados de utilizacaode servicos de telecomunicacoes, p.67, paper 24.http://inforum.org.pt/INForum2017/docs/comunicacoes-do-inforum2017, outubro2017. Consultado em 12 de fevereiro de 2018.https://web.archive.org/web/20180709185906/http://inforum.org.pt/INForum2017/docs/comunicacoes-do-inforum2017.

[73] Striim. Microsoft SQL Server CDC to Kafka - Striim.http://www.striim.com/microsoft-sql-server-cdc-to-kafka/. Consultado em 13 dejaneiro de 2017. https://web.archive.org/web/20160820053715/http://www.striim.com:80/microsoft-sql-server-cdc-to-kafka.

[74] Striim. MySQL CDC to Kafka - Striim.http://www.striim.com/mysql-cdc-to-kafka/. Consultado em 13 de janeiro de 2017.https://web.archive.org/web/20160819125148/http://www.striim.com:80/mysql-cdc-to-kafka.

[75] Justin Swanhart. Flexviews - materialized views for MySQL 5.1 - FlexCDC.http://flexviews.sourceforge.net/flexcdc.html. Consultado em 15 de setembro de2017. https://web.archive.org/web/20171016145558/http://flexviews.sourceforge.net/flexcdc.html.

[76] Ian H. Witten, Eibe Frank, Mark A. Hall, and Christopher J. Pal. Data Mining:Practical machine learning tools and techniques, fourth edition, capıtulo 1, p. 6,2016.



https://web.archive.org/web/20180709185906/http://inforum.org.pt/INForum2017/docs/comunicacoes-do-inforum2017

https://web.archive.org/web/20180709185906/http://inforum.org.pt/INForum2017/docs/comunicacoes-do-inforum2017

https://web.archive.org/web/20160820053715/http://www.striim.com:80/microsoft-sql-server-cdc-to-kafka

https://web.archive.org/web/20160820053715/http://www.striim.com:80/microsoft-sql-server-cdc-to-kafka

https://web.archive.org/web/20160819125148/http://www.striim.com:80/mysql-cdc-to-kafka

https://web.archive.org/web/20160819125148/http://www.striim.com:80/mysql-cdc-to-kafka

https://web.archive.org/web/20171016145558/http://flexviews.sourceforge.net/flexcdc.html

https://web.archive.org/web/20171016145558/http://flexviews.sourceforge.net/flexcdc.html

Capıtulo 9

Apendices

85

Capıtulo 9. Apendices 86

.1 Plano de Testes

Contents

As classes de equivalencia serao indicadas no formato: (@nome da variavel:tipo da variavel: classes).

.1.1 Testes unitarios ao conector SQL ServerTestes de caixa preta ao procedimento: usp AnalyseStrings

O valor de entrada e uma sequencia de caracteres:

• @toConvert: para converter proveniente de uma tabela alterada em producao:

As classes de equivalencia sao:

• @toConvert: NVARCHAR(MAX): NULL, comprimento=0,comprimento=]0,MAX[, comprimento=MAX, comprimento>MAX.

Tabela 1: Plano de testes de caixa preta ao procedimento usp AnalyseStrings

Casos de teste Valores de entradaNum. do teste (@toConvert)

1 (NULL)2 (”)3 (’Carl CHAR(9) Peterson CHAR(10)’)4 (’Lorem ipsum quia dolor sit amet...(ate ocupar 2Gb)’)5 (’Lorem ipsum quia dolor sit amet...(ate ocupar 3Gb)’)

Tabela 2: Resultados dos testes de caixa preta ao procedimento usp AnalyseStrings

CasosValores esperados Valores obtidosde

testeNum. do teste (@converted) (@converted)

1 (NULL) (NULL)2 (”) (”)3 (’Carl\t Peterson\n’) (’Carl\t Peterson\n’)

4(’Lorem ipsum quia (’Lorem ipsum quia

dolor sit amet...(ate 2Gb)’) dolor sit amet...(ate 2Gb)’

5(’Lorem ipsum quia (’Lorem ipsum quia

dolor sit amet...(ate 3Gb)’) dolor sit amet...(ate 3Gb)’)


Garante-se a RACC para o parametro @toConvert com os testes numero 1, 2 e 3 databela de testes para este procedimento.

1. O caso de teste e: converter uma sequencia de caracteres a NULL.

• Pretende verificar-se se o procedimento devolve NULL quando a sequenciade caracteres a converter e NULL.

• O parametro de entrada e uma sequencia de caracteres:

– a NULL.

• O resultado esperado e uma sequencia de caracteres:

– a NULL.

• O resultado obtido e: o esperado.

2. O caso de teste e: converter uma sequencia de caracteres vazia.

• Pretende verificar-se se o procedimento devolve uma sequencia de caracteresvazia semelhante a fornecida.


– vazia.


– vazia.


3. O caso de teste e: converter uma sequencia de caracteres de comprimento entre 0 eMAX(2Gb).

• Pretende testar-se se o procedimento processa sequencias de caracteres comum comprimento valido.


– ’abcASCII(10)def’.


– convertida a partir da fornecida.’abc\ndef’.


4. O caso de teste e: converter uma sequencia de caracteres de comprimento MAX(2Gb).


• Pretende testar-se se o procedimento converte sequencias de caracteres comum comprimento igual ao limite do seu tipo.


– de comprimento 2Gb.’Lorem ipsum quia dolor sit amet...’.


– de comprimento 2Gb convertida.’Lorem ipsum quia dolor sit amet...’.


5. O caso de teste e: converter uma sequencia de caracteres de comprimento maiorque MAX (2Gb).

• Pretende testar-se se o procedimento converte sequencias de caracteres comum comprimento maior que o limite do seu tipo.


– de comprimento 3Gb.’Lorem ipsum quia dolor sit amet...’.


– de comprimento 3Gb convertida.’Lorem ipsum quia dolor sit amet...’.


A partir daqui nao sao apresentados os testes aos limites superiores dosargumentos do tipo NVARCHAR(MAX) pois foram observados resultadossemelhantes para sequencias de caracteres de comprimento igual ou superior aolimite.

Os procedimentos e funcoes que compoem o conector foram desenvolvidos pararespeitar os limites dos tipos dos parametros e variaveis. Apesar dos testesrealizados nao serem suficientemente abrangentes para permitirem retirarconclusoes, aparentemente para o tipo de dados NVARCHAR(MAX) o limitemaximo do comprimento das sequencias de caracteres nao e verificadorigorosamente pelo SGBD.


Testes de caixa branca ao procedimento: usp AnalyseStrings

6. O caso de teste e: converter uma sequencia de caracteres sem caracteres especiais.

• Pretende verificar-se se o procedimento nao altera as sequencias de caracteressem caracteres especiais.


– sem caracteres especiais.’abcdef’.


– semelhante a fornecida.’abcdef’.


7. O caso de teste e: converter uma sequencia de caracteres ja convertida.

• Pretende verificar-se se o procedimento altera uma sequencia de caracterespreviamente convertida.


– igual a fornecida.


8. O caso de teste e: converter uma sequencia de caracteres com todos os caracteresespeciais suportados.

• Pretende testar-se se o procedimento prepara a sequencia de caracteres paraincluir no JSON convertendo os caracteres especiais e adicionando caracteresde escape ’\’.


– com todos os caracteres especiais suportados.’a\b/c "d"e ASCII(8) f ASCII(9) g ASCII(10) h

ASCII(11) i ASCII(12) j ASCII(13) l’.


– convertida correspondente a fornecida.’a\\b\/c \"d\"e \b f \t g \n h \v i \f j \r l’.



Testes de caixa branca ao procedimento: usp CleanupCDCAlterations

9. O caso de teste e: remover as alteracoes enviadas quando nao existem alteracoesregistadas.

• Pretende verificar-se o comportamento do procedimento quando e chamado alimpar alteracoes e nao existe nenhuma alteracao registada.

• Os resultados esperados sao:

– nenhuma linha da tabela alterada.

• Os resultados obtidos sao: os esperados.

10. O caso de teste e: remover as alteracoes enviadas quando existem alteracoesregistadas que ainda nao foram enviadas.

• Pretende verificar-se o comportamento do procedimento quando e chamado alimpar alteracoes que ainda nao foram enviadas.


– nenhuma linha da tabela alterada.


11. O caso de teste e: remover as alteracoes enviadas quando apenas algumas dasalteracoes registadas ja foram enviadas.

• Pretende verificar-se o comportamento do procedimento quando e chamado alimpar alteracoes que ja foram enviadas mas ja existem novas alteracoes porenviar.


– remove todas as alteracoes enviadas.

– mantem as alteracoes por enviar.

• Os resultados obtidos sao:

– remove todas as alteracoes enviadas excepto as registadas no mesmosegundo do ultimo envio.

– mantem as alteracoes por enviar.

12. O caso de teste e: remover as alteracoes enviadas quando todas as alteracoesregistadas ja foram enviadas.

• Pretende verificar-se o comportamento do procedimento quando e chamado alimpar alteracoes que ja foram enviadas.



– remover todas as alteracoes.


– remover todas as alteracoes quando nao ha alteracoes ja enviadas queforam registadas no mesmo segundo do ultimo envio.

Testes de caixa preta ao procedimento: usp ConvertJSONType

Os valores de entrada sao as seguintes sequencias de caracteres:

• @ConfigCDCTableName: o nome da tabela de configuracao.

• @FullTableName: o nome da tabela a utilizar no comando formatado.

• @ColName: o nome da coluna a utilizar no comando formatado.


• @ConfigCDCTableName: NVARCHAR(MAX): NULL, comprimento=0,comprimento=]0,MAX[.

• @FullTableName: NVARCHAR(MAX) NULL, comprimento=0,comprimento=]0,MAX[.

• @ColName: NVARCHAR(MAX) NULL, comprimento=0,comprimento=]0,MAX[.

Tabela 3: Plano de testes de caixa preta ao procedimento usp ConvertJSONType

Casos de teste Valores de entradaNum. do teste (@ConfigCDCTableName, @FullTableName, @ColName)

1 (NULL, NULL, NULL)2 (’ConfigCDCTable’, ’dbo Employee CT’, NULL)3 (’ConfigCDCTable’, ’dbo Employee CT’, ”)4 (’ConfigCDCTable’, ’dbo Employee CT’, ’Name’)

Garante-se a RACC para o parametro @ColName com os testes numero 2, 3 e 4da tabela de testes para este procedimento.

13. O caso de teste e: formatar um comando para ser executado pelo SQL dinamicocom todos os parametros a NULL.

• Pretende testar-se se o procedimento funciona sem lhe fornecer o nome databela de configuracao, o nome da tabela e o nome da coluna em questao poistodos os argumentos sao passados a NULL.


• Os parametros de entrada sao duas sequencias de caracteres:

– ambas a NULL.


– a NULL.


14. O caso de teste e: formatar um comando para ser executado pelo SQL dinamicosem fornecer o nome da coluna.

• Pretende testar-se se o procedimento funciona sem lhe fornecer o nome dacoluna mas fornecendo-lhe o nome da tabela de configuracao e o nome databela onde estao os dados a formatar.


– uma com o nome da tabela de configuracao.

– uma com o nome da tabela com os dados a formatar.


– a NULL.



• Pretende testar-se se o procedimento funciona com o nome da coluna vazio,fornecendo-lhe apenas o nome da tabela de configuracao e o nome da tabelaonde estao os dados a formatar.

• Os parametros de entrada sao sequencias de caracteres:



– uma com o nome da coluna vazia.


– a NULL.



• Pretende testar-se se o procedimento funciona fornecendo-lhe todos osparametros validos.





– uma com o nome da coluna que tem os dados a formatar.


– com um comando para o SQL dinamico executar e obter os dados deuma coluna formatada em JSON.’{"col":"Name","oldval":’’+ISNULL(’’"’’+CONVERT(NVARCHAR(MAX), @convName, 1)+

’’"’’, ’’NULL’’)+’’,"val":’’+ISNULL(’’"’’+

CONVERT(NVARCHAR(MAX), @convnewName, 1)+

’’"’’, ’’NULL’’)+’’,"type":"String"}’.


Testes de caixa branca ao procedimento: usp ConvertJSONType

Os parametros de entrada sao sequencias de caracteres:

• uma com o nome da tabela de configuracao do conector.

• uma com o nome da tabela onde sao registadas as alteracoes.

• uma com o nome da coluna a formatar.

17. O caso de teste e: formatar um comando para ser executado pelo SQL dinamicopara produzir o JSON de uma coluna de um tipo nao suportado.

• Pretende verificar-se a formatacao do codigo SQL dinamico que produz umacoluna JSON sem adicionar valores.

• Os resultados esperados sao duas sequencias de caracteres:

– que depois de executadas produzirao o JSON apenas com o nome dacoluna sem adicionar valores.

– @FormatColJSON: ’{"col":" $start lsn","val":NULL,

"type":"Unsupported"}’ .

– @FormatUpdateColJSON: ’{"col":" $start lsn",

"oldval":NULL,"val":NULL,"type":"Unsupported"}’ .


18. O caso de teste e: formatar um comando para ser executado por SQL dinamicopara produzir o JSON de uma coluna com uma marca temporal.


• Pretende verificar-se a formatacao do codigo SQL dinamico que produz umacoluna JSON com uma data e hora.


– que depois de executadas produzirao o JSON apenas com a marcatemporal atual presente na coluna ou tambem com a anterior.

– @FormatColJSON: ’{"col":"Since","val":’’+ISNULL(’’"’’+

SUBSTRING(CONVERT(NVARCHAR(MAX),

CONVERT(DATETIME, @Since), 126), 1, 19)+

’’"’’, ’’NULL’’)+’’,"type":"Timestamp"}’ .

– @FormatUpdateColJSON: ’{"col":"Since","oldval":’’+ISNULL(’’"’’+


CONVERT(DATETIME, @oldSince), 126), 1, 19)+

’’"’’, ’’NULL’’)+’’,"val":’’+ISNULL(’’"’’+


CONVERT(DATETIME, @Since), 126), 1, 19)+

’’"’’, ’’NULL’’)+’’,"type":"Timestamp"}’ .


19. O caso de teste e: formatar um comando para ser executado por SQL dinamicopara produzir o JSON de uma coluna com uma sequencia de caracteres.

• Pretende verificar-se a formatacao do codigo SQL dinamico que produzauma coluna JSON com uma sequencia de caracteres.


– que depois de executadas produzirao o JSON apenas com a sequencia decaracteres atual da coluna ou tambem com a sequencia anterior.


CONVERT(NVARCHAR(MAX), @convName, 1)

+’’"’’, ’’NULL’’)+’’,"type":"String"}’ .


CONVERT(NVARCHAR(MAX), @convOldName, 1)

+’’"’’, ’’NULL’’)+’’,"val":’’+ISNULL(’’"’’+

CONVERT(NVARCHAR(MAX), @convName’, 1)+

’’"’’, ’’NULL’’)+’’,"type":"String"}’ .



20. O caso de teste e: formatar um comando para ser executado porSQLdinamico paraproduzir o JSON de uma coluna com um numero.

• Pretende verificar-se a formatacao do codigo SQL dinamico que produz umacoluna JSON com um numero.


– que depois de executadas produzirao o JSON apenas com o numeroatual ou tambem com o anterior.


CONVERT(NVARCHAR(MAX), @Pay, 1)

+’’"’’, ’’NULL’’)+’’,"type":"Decimal"}’ .


CONVERT(NVARCHAR(MAX), @oldPay, 1)

+’’"’’, ’’NULL’’)+’’,"val":’’+ISNULL(’’"’’+

CONVERT(NVARCHAR(MAX), @Pay’, 1)+

’’"’’, ’’NULL’’)+’’,"type":"Decimal"}’ .


Testes de caixa preta ao procedimento: usp DescribeTable



• @TableName: o nome da tabela a utilizar no comando formatado.

• @FullTableName: o nome da tabela a utilizar no comando formatado.

• @CDCTableRegistryName: o nome da tabela auxiliar de registo domecanismo CDC.

• @TS ColumnName: o nome da coluna que tem as marcas temporais aconsiderar.

• @TS RowVersion: a marca temporal a partir da qual se pretende obter asalteracoes.


• @ConfigCDCTableName: NVARCHAR(MAX) NULL, comprimento=0,comprimento=]0,MAX[.


• @TableName: NVARCHAR(MAX) NULL, comprimento=0,comprimento=]0,MAX[.

• @FullTableName: NVARCHAR(MAX) NULL, comprimento=0,comprimento=]0,MAX[.

• @CDCTableRegistryName: NVARCHAR(MAX) NULL, comprimento=0,comprimento=]0,MAX[.

• @TS ColumnName: NVARCHAR(MAX) NULL, comprimento=0,comprimento=]0,MAX[.

• @TS RowVersion: NVARCHAR(MAX) NULL, comprimento=0,comprimento=]0,MAX[.

Tabela 4: Plano de testes de caixa preta ao procedimento usp DescribeTable

Casos de teste Valores de entrada

Num. do teste(@ConfigCDCTableName, @TableName, @FullTableName,

@CDCTableRegistryName, @TS ColumnName, @TS RowVersion)

1(NULL, NULL, NULL,NULL, NULL, NULL)

2(’ConfigCDCTable’, NULL, NULL,

’CDCAuxTableRegistry’, NULL, NULL)

3(’ConfigCDCTable’, ”, ”,


4(’ConfigCDCTable’, ’Employee’, ’cdc.dbo Employee CT’,



NULL, ’LastAlteration’, NULL)


NULL, ’LastAlteration’, ”)


NULL, ’LastAlteration’, ’11:25:12 08-02-2017’)

Garante-se a RACC para os parametros @TableName e @FullTableName comos testes numero 2, 3 e 4 da tabela de testes para este procedimento.

Garante-se a RACC para o parametro @TS RowVersion com os testes 5, 6 e 7.

Aplica-se o criterio de cobertura dos testes a tres parametros porque os doisprimeiros estao profundamente relacionados e o terceiro e o parametro maisdinamico.


Tabela 5: Resultados dos testes de caixa preta ao procedimento usp DescribeTable


testeNum. do teste (@OperationsList, @TableJSON) (@OperationsList, @TableJSON)

1 (NULL,NULL) (NULL,NULL)2 (NULL,NULL) (NULL,NULL)3 (NULL,NULL) (NULL,NULL)

4

(’”INSERT”’,’{ (’”INSERT”’,’{”rowid”:”00000059000060A10003”, ”rowid”: ”00000059000060A10003”,

”seq”:1,”operations”:”INSERT”, ”seq”:1,”operations”: ”INSERT”,”data”:[{”col”:”EmployeeID”, ”data”: [{”col”:”EmployeeID”,

”val”:”9079”,”type”:”Decimal”},{ ”val”:”9079”,”type”:”Decimal”},{”col”:”Name”,”val”:”Carl Peterson”, ”col”:”Name”,”val”: ”Carl Peterson”,

”type”:”String”}]}’) ”type”:”String”}]}’)5 (NULL,NULL) (NULL,NULL)6 (NULL,NULL) (NULL,NULL)

7




”type”:”String”},{’) ”type”:”String”},{’)”col”:”LastAlteration”, ”col”:”LastAlteration”,

”val”:”11:47:09 08-02-2017”, ”val”:”11:47:09 08-02-2017”,”type”:”Timestamp”}]}’) ”type”:”Timestamp”}]}’)

21. O caso de teste e: formatar um comando para ser executado pelo SQL dinamicocom todos os parametros a NULL.

• Pretende testar-se se o procedimento funciona com todos os argumentos aNULL.


– todas a NULL.


– ambas a NULL.


22. O caso de teste e: formatar um comando para ser executado pelo SQL dinamicoomitindo os quatro parametros mais dinamicos.


• Pretende testar-se se o procedimento funciona se receber apenas o nome dastabelas utilizadas pelo conector e os outros parametros a NULL.


– uma com o nome da tabela de configuracao do conector.

– uma com o nome da tabela auxiliar de registo do conector.

– quatro a NULL.


– ambas a NULL.


23. O caso de teste e: formatar um comando para ser executado pelo SQL dinamicofornecendo dois nomes de tabelas vazios.

• Pretende testar-se se o procedimento funciona se receber apenas o nome dastabelas utilizadas pelo conector e o nome das outras tabelas vazio.



– duas vazias, uma representa o nome da tabela para obter alteracoes e aoutra o nome completo da mesma tabela.


– duas a NULL.

• Os resultados esperados sao sequencias de caracteres:

– ambas a NULL.


24. O caso de teste e: formatar um comando para ser executado pelo SQL dinamicofornecendo todos os nomes das tabelas.

• Pretende testar-se se o procedimento funciona se receber apenas o nome dastabelas utilizadas pelo conector e o nome das tabelas para obter alteracoes.



– uma com o nome da tabela para obter alteracoes.

– uma com o nome completo da tabela para obter alteracoes.


– duas a NULL.



– uma com a lista das operacoes registadas nas alteracoes.’"INSERT"’ .

– uma com o JSON formatado com as alteracoes.’{ "rowid": "00000059000060A10003",

"seq": 1,

"operations": "INSERT",

"data": [{"col": "EmployeeID",

"val": "9079",

"type": "Decimal"

}, {"col": "Name",

"val": "Carl Peterson",

"type": "String"

}’


25. O caso de teste e: formatar um comando para ser executado pelo SQL dinamicosem fornecer a marca temporal mas fornecendo o nome da coluna.

• Pretende testar-se se o procedimento funciona se receber o nome da colunade referencia mas nao receber a marca temporal.





– uma a NULL.

– uma com o nome da coluna de referencia das marcas temporais.

– uma a NULL.


– ambas a NULL.


26. O caso de teste e: formatar um comando para ser executado pelo SQL dinamicofornecendo a marca temporal vazia e o nome da coluna de referencia.

• Pretende testar-se se o procedimento funciona se receber a marca temporalvazia e o nome da coluna de referencia.






– uma a NULL.


– uma com a marca temporal vazia.


– ambas a NULL.


27. O caso de teste e: formatar um comando para ser executado pelo SQL dinamicofornecendo o nome da coluna de referencia e a marca temporal de limite.

• Pretende testar-se se o procedimento funciona se receber as tabelas ondeobter os dados, o nome da coluna de referencia e a marca temporal queestabelece o limite das alteracoes a obter.





– uma a NULL.


– uma com a marca temporal.



– uma com o JSON formatado com as alteracoes apos a marca temporalfornecida.’{ "rowid": "00000059000060A10003",

"seq": 1,



"val": "9079",

"type": "Decimal"

}, {


"col": "Name",


"type": "String"

}, {"col": "LastAlteration",

"val": "11:47:09 08-02-2017",

"type": "Timestamp"

}’


Testes de caixa branca ao procedimento: usp DescribeTable

Os parametros de entrada sao sequencias de caracteres com:

• o nome da tabela de configuracao do conector.

• o nome da tabela onde ocorreram alteracoes.

• o nome da tabela onde foram registadas as alteracoes.

• o nome da tabela auxiliar onde o conector regista as tabelas onde devecapturar alteracoes.

• o nome da coluna da tabela onde se registam marcas temporais de alteracaodas linhas.

• a marca temporal a partir da qual se pretende obter alteracoes.

28. O caso de teste e: produzir JSON de todas as alteracoes registadas de uma tabela.

• Pretende verificar-se a composicao do JSON com todas as linhas alteradas deuma tabela.

• Os parametros de entrada especıficos sao duas sequencias de caracteres:

– o nome da coluna da tabela a NULL.

– a marca temporal a NULL.


– uma com a lista de operacoes das alteracoes registadas na tabela.’"DELETE"’ .

– uma com o JSON de todas as linhas alteradas da tabela.’{"rowid": "00000059000060A60002",

"seq": 1,

"operations": "DELETE",



"oldval": "9079",

"type": "Decimal"

}, {"col": "FirstName",

"oldval": "Carl Peterson",

"type": "String"

}]}’ .


29. O caso de teste e: produzir JSON das alteracoes de uma tabela apos uma marcatemporal.

• Pretende verificar-se a composicao do JSON com as linhas alteradas de umatabela apos uma marca temporal.

• O parametro de entrada especıfico e uma sequencia de caracteres:

– o nome da tabela auxiliar a NULL.


– uma com a lista das operacoes registadas na tabela.’"INSERT"’ .

– uma com o JSON com todas as linhas alteradas da tabela apos a marcatemporal.{"rowid": "0x0003000001000000",

"seq": 1,



"val": "6",

"type": "Decimal"

}, {"col": "Name",

"val": "John Adams",

"type": "String"

}, {"col": "Since",

"val": "2017-02-10T11:53:38",


"type": "Timestamp"

}]}


Testes de caixa preta ao procedimento: usp FetchTableAlterations


• @TableName: o nome da tabela onde capturar alteracoes.

• @CDCTableRegistryName: o nome da tabela auxiliar de registo do conector.

• @ColsDeclaration: o SQL dinamico para declarar as colunas da tabela.

• @ListOfVariables: uma lista com as variaveis utilizadas pelo SQL dinamico.

• @ListOfNewVars: uma lista com as variaveis utilizadas pelo SQL dinamicopara guardar os valores antigos das atualizacoes de linhas da tabela.

• @ListOfColNames: uma lista com o nome das colunas da tabela.

• @FormatColJSON: SQL dinamico para formatar o JSON de uma colunaalterada da tabela.

• @FormatUpdateColJSON: o SQL dinamico para formatar o JSON com osvalores antigos das atualizacoes.

• @AnalyseVars: o SQL dinamico para analisar as variaveis.

• @AnalyseNewVars: SQL dinamico para analisar as novas variaveis quesuportam os valores antigos das atualizacoes de linhas da tabela.

• @TS ColumnName: o nome da coluna da tabela a usar como referencia paraprocurar as marcas temporais.

• @TS RowVersion: a marca temporal a utilizar como referencia paraselecionar as alteracoes a incluir no JSON.

As classes de equivalencia sao as mesmas para todos os parametros de entrada:

• NVARCHAR(MAX): NULL, comprimento=0, comprimento=]0,MAX[.

Garante-se a RACC para os parametros @TS ColumnName e@TS RowVersion com os testes 2, 3 e 4 da tabela de testes para esteprocedimento.


Tabela 6: Plano de testes de caixa preta ao procedimento usp FetchTableAlterations


Num. do teste

(@TableName, @CDCTableRegistryName, @ColsDeclaration,@ListOfVariables, @ListOfNewVars, @ListOfColNames,

@FormatColJSON, @FormatUpdateColJSON, @AnalyseVars,@AnalyseNewVars, @TS ColumnName, @TS RowVersion)

1

(NULL, NULL, NULL,NULL, NULL, NULL,NULL, NULL, NULL,NULL, NULL, NULL)

2

(’Employee’, ’CDCAuxTableRegistry’, ’DECLARE @ start lsn, ...’,’@ start lsn,...’, ’@new start lsn,...’, ’ start lsn,...’,

’”col”:” start lsn”,”val”...’, ’”col”:” start lsn”,”oldval”...,’’DECLARE @conv start lsn,...’,

’DECLARE @convnew start lsn,...’, NULL, NULL)

3



’DECLARE @convnew start lsn,...’, ”, ”)

4



’DECLARE @convnew start lsn,...’, ’Since’, ’2017-05-10T14:37:51’)

Aplica-se o criterio de cobertura dos testes a dois parametros devido a relacaoque existe entre eles, um indica a marca temporal que deve ser considerada comolimite para capturar alteracoes e o outro o nome da coluna onde estao as marcastemporais a considerar.

30. O caso de teste e: executar o SQL dinamico com todos os parametros a NULL.



– todas a NULL.


– ambas a NULL.


31. O caso de teste e: executar o SQL dinamico apenas com dois parametros a NULL.


Tabela 7: Resultados dos testes de caixa preta ao procedimento usp FetchTableAlterati-ons


testeNum. do teste (@OperationsList, @RowJSON) (@OperationsList, @RowJSON)

1 (NULL,NULL) (NULL,NULL)

2




”type”:”String”}]}’) ”type”:”String”}]}’)

3





4





• Pretende testar-se se o procedimento funciona com os dois parametrosrelacionados com marcas temporais a NULL.


– uma com o nome da tabela para capturar alteracoes.


– uma lista com as colunas da tabela para usar num cursor.

– uma lista com a declaracao de uma variavel para cada coluna.

– uma lista com a declaracao de variaveis adicionais para cada coluna.

– uma lista com as colunas da tabela para usar numa pesquisa a BD.

– uma com o JSON a ser utilizado nas insercoes e remocoes de dadosregistadas.

– uma com o JSON a ser utilizado nas alteracoes de dados registadas.


– uma com o codigo dinamico que submete os dados para analise econversao de caracteres especiais.

– uma com o nome da coluna e outro com uma marca temporal, ambas aNULL.




"seq": 1,



"val": "9079",

"type": "Decimal"

}, {"col": "Name",


"type": "String"

}’


32. O caso de teste e: executar o SQL dinamico apenas com dois parametros vazios.

• Pretende testar-se se o procedimento funciona com os dois parametrosrelacionados com marcas temporais vazios.












– uma com o nome da coluna e outro com uma marca temporal, ambasvazias.


– uma com a lista das operacoes registadas nas alteracoes.’"INSERT"’.


"seq": 1,



"val": "9079",

"type": "Decimal"

}, {"col": "Name",


"type": "String"

}’


33. O caso de teste e: executar o SQL dinamico com todos os parametros preenchidos.

• Pretende testar-se se o procedimento funciona com todos os parametrospreenchidos.











– uma com o nome da coluna das marcas temporais da ultima alteracao.

– uma com a marca temporal usada como referencia para obter alteracoes.





"seq": 1,



"val": "9079",

"type": "Decimal"

}, {"col": "Name",


"type": "String"

}’


Testes de caixa branca ao procedimento: usp FetchTableAlterations

Os parametros de entrada sao sequencias de caracteres:

• uma com o nome da tabela para capturar alteracoes.

• uma lista com as colunas da tabela para usar num cursor.

• uma lista com a declaracao de uma variavel para cada coluna.

• uma lista com a declaracao de variaveis adicionais para cada coluna.

• uma lista com as colunas da tabela para usar numa pesquisa a BD.

• uma com o JSON a ser utilizado nas insercoes e remocoes de dadosregistadas.

• uma com o JSON a ser utilizado nas alteracoes de dados registadas.

• uma com o codigo dinamico que submete os dados para analise e conversaode caracteres especiais.

34. O caso de teste e: executar SQL dinamico adaptado a tabela em questao para obteras suas alteracoes apos uma marca temporal.

• Pretende verificar-se a execucao do SQL dinamico previamente construıdopara produzir JSON das alteracoes de uma determinada tabela apos umamarca temporal.


• Os parametros de entrada especıficos sao tres sequencias de caracteres:

– uma com o nome da tabela auxiliar de registo do conector a NULL.

– uma com o nome da coluna das marcas temporais da ultima alteracao.

– uma com a marca temporal usada como referencia para obter alteracoes.




"seq": 1,



"val": "9079",

"type": "Decimal"

}, {"col": "Name",


"type": "String"


"val": "11:47:09 08-02-2017",

"type": "Timestamp"

}’


35. O caso de teste e: executar SQL dinamico adaptado a tabela em questao para obteruma atualizacao.

• Pretende verificar-se a execucao do SQL dinamico previamente construıdopara produzir JSON da atualizacao de uma linha da tabela.

• Os parametros de entrada especıficos sao tres sequencias de caracteres:


– uma com o nome da coluna das marcas temporais da ultima alteracao aNULL.

– uma com a marca temporal usada como referencia para obter alteracoesa NULL.



– uma com a lista das operacoes registadas nas alteracoes.’"UPDATE"’.


"seq": 1,

"operations": "UPDATE",


"oldval": "9079",

"val": "9079",

"type": "Decimal"

}, {"col": "Name",

"oldval": "Carl Kennedy",


"type": "String"


"oldval": "11:47:09 08-02-2017",

"val": "11:52:32 08-02-2017",

"type": "Timestamp"

}’


Testes de caixa preta ao procedimento: usp GetCustomResults


• @ConfigCDCTableName: o nome da tabela de configuracao do conector.

• @FullTableName: o nome da tabela a utilizar para obter dados.

• @ColName: o nome da coluna a utilizar para obter dados.

As classes de equivalencia sao as mesmas para todos os parametros de entrada:

• NVARCHAR(MAX): NULL, comprimento=0, comprimento=]0,MAX,[.

Garante-se a RACC para o parametro @ColName com os testes 2, 3 e 4 databela de testes para este procedimento.


Tabela 8: Plano de testes de caixa preta ao procedimento usp GetCustomResults

Casos de teste Valores de entradaNum. do teste (@ConfigCDCTableName, @FullTableName, @ColName)

1 (NULL, NULL, NULL)2 (’ConfigCDCTable’, ’dbo Employee CT’, NULL)3 (’ConfigCDCTable’, ’dbo Employee CT’, ”)4 (’ConfigCDCTable’, ’dbo Employee CT’, ’Name’)

Tabela 9: Resultados dos testes de caixa preta ao procedimento usp GetCustomResults


testeNum. (@ColsDeclaration, @ListOfVariables, (@ColsDeclaration, @ListOfVariables,

do @ListOfNewVars, @ListOfColNames, @ListOfNewVars, @ListOfColNames,teste @AnalyseVars, @AnalyseNewVars) @AnalyseVars, @AnalyseNewVars)

1 (NULL,NULL) (NULL,NULL)2 (NULL,NULL) (NULL,NULL)3 (NULL,NULL) (NULL,NULL)

4

(’DECLARE @ start lsn, ...’, ’DECLARE @ start lsn, ...’,’@ start lsn,...’, ’@ start lsn,...’,

’@new start lsn,...’, ’ start lsn,...’, ’@new start lsn,...’, ’ start lsn,...’,’DECLARE @conv start lsn,...’, ’DECLARE @conv start lsn,...’,

’DECLARE @convnew start lsn,...’ ’DECLARE @convnew start lsn,...’

Aplica-se o criterio de cobertura dos testes a este parametro por ser o maisdinamico.

36. O caso de teste e: obter os dados sobre as colunas com todos os parametros aNULL.


• Os parametros de entrada sao tres sequencias de caracteres:

– todas a NULL.

• Os resultados esperados sao seis sequencias de caracteres:

– todas a NULL.


37. O caso de teste e: obter os dados sobre as colunas com o nome da coluna a NULL.

• Pretende testar-se se o procedimento funciona com o nome da coluna aNULL.




– uma com o nome da tabela para obter dados.

– uma com o nome da coluna da tabela a NULL.


– todas a NULL.


38. O caso de teste e: obter os dados sobre as colunas com o nome da coluna vazia.

• Pretende testar-se se o procedimento funciona com o nome da coluna vazia.




– uma com o nome da coluna da tabela vazia.


– todas a NULL.


39. O caso de teste e: obter os dados sobre as colunas com todos os parametrospreenchidos.

• Pretende testar-se se o procedimento funciona com todos os parametrospreenchidos.




– uma com o nome da coluna da tabela.






– uma com o codigo dinamico que submete os dados de insercoes eremocoes de linhas para analise e conversao de caracteres especiais.

– uma com o codigo dinamico que submete os dados de atualizacoes delinhas para analise e conversao de caracteres especiais.



Testes de caixa branca ao procedimento: usp GetCustomResults



• o nome da tabela a utilizar no comando formatado.

• o nome da coluna da tabela a utilizar no comando formatado.

40. O caso de teste e: formatar SQL dinamico para inicializar as variaveis necessariaspara manipular as alteracoes de uma tabela existente.

• Pretende preparar-se o SQL dinamico que formatara o JSON das alteracoescapturadas de uma tabela existente.






– uma com o codigo dinamico que submete os dados de insercoes eremocoes de linhas para analise e conversao de caracteres especiais.

– uma com o codigo dinamico que submete os dados de atualizacoes delinhas para analise e conversao de caracteres especiais.


41. O caso de teste e: formatar SQL dinamico para inicializar as variaveis necessariaspara manipular as alteracoes de uma tabela inexistente.

• Pretende verificar-se se e formatado algum SQL dinamico quando a tabelaindicada nao existe.


– todas a NULL.


42. O caso de teste e: formatar SQL dinamico para inicializar as variaveis necessariaspara manipular as alteracoes numa coluna inexistente.

• Pretende verificar-se se e formatado algum SQL dinamico quando a colunaindicada nao existe na tabela.


– todas a NULL.



Testes de caixa preta ao procedimento: usp GetLastRows


• @TableName: o nome da tabela para capturar alteracoes.

• @TS ColumnName: o nome da coluna com as marcas temporais em queocorreu a ultima alteracao em cada linha da tabela.

• @TS RowVersion: a marca temporal a partir da qual se pretendem capturaras alteracoes.



• @TS ColumnName: NVARCHAR(MAX) NULL, comprimento=0,comprimento=]0,MAX[.

• @TS RowVersion: NVARCHAR(MAX) NULL, comprimento=0,comprimento=]0,MAX[.

Tabela 10: Plano de testes de caixa preta ao procedimento usp GetLastRows

Casos de teste Valores de entradaNum. do teste (@TableName, @TS ColumnName, @TS RowVersion)

1 (NULL, NULL, NULL)2 (’Employee’, ’LastAlteration’, NULL)3 (’Employee’, ’LastAlteration’, ”)4 (’Employee’, ’LastAlteration’, ’11:52:32 08-02-2017’)

Garante-se a RACC para o parametro @TS RowVersion com os testes numero2, 3 e 4 da tabela de testes para este procedimento.

43. O caso de teste e: obter as ultimas linhas alteradas de uma tabela com todos osparametros a NULL.

• Pretende testar-se se o procedimento funciona sem lhe fornecer o nome databela, o nome da coluna e a marca temporal pois todos os argumentos saopassados a NULL.


– todas a NULL.



– zero linhas alteradas.


44. O caso de teste e: obter as ultimas linhas alteradas de uma tabela fornecendo amarca temporal a NULL.

• Pretende testar-se se o procedimento funciona sem lhe fornecer a marcatemporal a partir da qual deve obter as linhas alteradas.



– uma com o nome da coluna com as marcas temporais.

– uma com a marca temporal de referencia a NULL.




45. O caso de teste e: obter as ultimas linhas alteradas de uma tabela fornecendo amarca temporal vazia.

• Pretende testar-se se o procedimento funciona fornecendo uma marcatemporal vazia para usar como referencia na obtencao das linhas alteradas.




– uma com a marca temporal de referencia vazia.




46. O caso de teste e: obter as ultimas linhas alteradas de uma tabela.

• Pretende testar-se se o procedimento funciona fornecendo todos osparametros com valores validos.




– uma com uma marca temporal de referencia.



– todas as linhas que foram alteradas apos a marca temporal fornecida.


Testes de caixa branca ao procedimento: usp GetLastRows


• o nome da tabela para capturar alteracoes.

• o nome da coluna da tabela onde se registam as marcas temporais dealteracao das linhas.

• a marca temporal a partir da qual se pretende obter alteracoes.

47. O caso de teste e: obter as alteracoes de uma tabela inexistente.

• Pretende verificar-se se sao obtidas alteracoes quando a tabela indicada naoexiste.




48. O caso de teste e: obter as alteracoes de uma tabela indicando uma coluna que naotem marcas temporais.

• Pretende verificar-se se sao obtidas alteracoes de uma tabela quando naoexistem marcas temporais para comparar com a de referencia.




49. O caso de teste e: obter as alteracoes de uma tabela indicando uma coluna que temas marcas temporais de insercao das linhas.

• Pretende verificar-se se sao obtidas alteracoes de uma tabela quando a colunaindicada tem marcas temporais que nao sao atualizadas quando existemalteracoes:


– as linhas adicionadas depois da marca temporal usada como referencia.



50. O caso de teste e: obter todas as alteracoes de uma tabela.

• Pretende verificar-se se o procedimento obtem todas as alteracoes de umatabela se for utilizada a primeira marca temporal valida: ”00:00:0001-01-0001”[9].


– todas as linhas da tabela.


51. O caso de teste e: obter as alteracoes de uma tabela apos uma marca temporal nofuturo.

• Pretende verificar-se a comparacao entre a marca temporal fornecida e asexistentes na coluna indicada.




52. O caso de teste e: obter as alteracoes de uma tabela apos uma marca temporalultrapassada.

• Pretende verificar-se se o procedimento obtem as ultimas alteracoes de umatabela.


– todas as linhas que foram alteradas apos a marca temporal fornecida.


Testes de caixa preta ao procedimento: usp GetTableColsList


• @ConfigCDCTableName: o nome da tabela de configuracao do conector.

• @TableName: o nome da tabela a utilizar no comando formatado.


• @ConfigCDCTableName: NVARCHAR(MAX) NULL, comprimento=0,comprimento=]0,MAX[.



Tabela 11: Plano de testes de caixa preta ao procedimento usp GetTableColsList

Casos de teste Valores de entradaNum. do teste (@ConfigCDCTableName, @TableName)

1 (NULL, NULL, NULL)2 (’ConfigCDCTable’, NULL)3 (’ConfigCDCTable’, ”)4 (’ConfigCDCTable’, ’dbo Employee CT’)

Tabela 12: Resultados dos testes de caixa preta ao procedimento usp GetTableColsList


testeNum. do teste (@ColsList) (@ColsList)

1 (NULL) (NULL)2 (NULL) (NULL)3 (NULL) (NULL)

4

(’DECLARE @EmployeeID Int; (’DECLARE @EmployeeID Int;DECLARE @newEmployeeID DECLARE @newEmployeeID

Int; DECLARE @Name Int; DECLARE @NameNVARCHAR(MAX); NVARCHAR(MAX);

DECLARE @newName DECLARE @newNameNVARCHAR(MAX);’) NVARCHAR(MAX);’)

Garante-se a RACC para o parametro @TableName com os testes numero 2, 3 e4 da tabela de testes para este procedimento.

53. O caso de teste e: formatar codigo SQL dinamico para declarar duas variaveis porcoluna sem indicar o nome das tabelas.

• Pretende testar-se se o procedimento funciona sem o nome da tabela deconfiguracao nem o nome da tabela pois todos os argumentos sao passados aNULL.


– ambas a NULL.


– a NULL.


54. O caso de teste e: formatar codigo SQL dinamico para declarar duas variaveis porcoluna apenas com o nome da tabela de configuracao.


• Pretende testar-se se o procedimento funciona apenas com o nome da tabelade configuracao pois o nome da tabela e passado a NULL.



– uma com o nome da tabela a NULL.


– a NULL.


55. O caso de teste e: formatar codigo SQL dinamico para declarar duas variaveis porcoluna de uma tabela com o nome vazio.

• Pretende testar-se se o procedimento funciona com o nome da tabela vazio.



– uma com o nome da tabela vazio.


– a NULL.


56. O caso de teste e: formatar codigo SQL dinamico para declarar duas variaveis porcoluna de uma tabela indicada.

• Pretende testar-se se para uma dada tabela o procedimento formata codigoSQL dinamico que declare duas variaveis por coluna.



– uma com o nome da tabela para declarar duas variaveis por coluna.

• O resultado esperado e uma sequencia de caracteres.

– ’DECLARE @EmployeeID Int; DECLARE @newEmployeeID Int;DECLARE @Name NVARCHAR(MAX); DECLARE @newNameNVARCHAR(MAX)’.



Testes de caixa branca ao procedimento: usp GetTableColsList



• o nome da tabela para declarar duas variaveis por coluna.

57. O caso de teste e: obter SQL dinamico que inicializa duas variaveis para cadacoluna de uma tabela inexistente.

• Pretende verificar-se se o procedimento formata SQL dinamico quando seindica uma tabela inexistente.


– a NULL.


58. O caso de teste e: obter SQL dinamico que inicializa duas variaveis para cadacoluna de uma tabela existente.

• Pretende formatar-se SQL dinamico para inicializar as variaveis necessariaspara receber uma linha alterada da tabela indicada.


– ’DECLARE @EmployeeID Int; DECLARE @newEmployeeID Int;DECLARE @Name NVARCHAR(MAX); DECLARE @newNameNVARCHAR(MAX)’.


Testes de caixa preta ao procedimento: usp MakeJSON



• @CDCTableRegistryName: o nome da tabela auxiliar de registo de tabelas.


• @TS ColumnName: o nome da coluna com as marcas temporais das ultimasalteracoes das linhas.

• @TS RowVersion: a marca temporal a utilizar como referencia para obteralteracoes.

As classes de equivalencia sao iguais para todos os parametros:



Tabela 13: Plano de testes de caixa preta ao procedimento usp MakeJSON


Num. do teste(@ConfigCDCTableName, @CDCTab leRegistryName,@TableName, @TS ColumnName, @TS RowVersion)

1 (NULL, NULL, NULL, NULL, NULL)

2(’ConfigCDCTable’, ’CDCAuxTableRegistry’,

NULL, NULL, NULL)


”, NULL, NULL)


’Employee’, NULL, NULL)

5(’ConfigCDCTable’, NULL,’Employee’, NULL, NULL)

6(’ConfigCDCTable’, NULL,

’Employee’, ”, ”)


’Employee’, ’LastAlteration’, ’11:52:32 08-02-2017’)

Garante-se a RACC para o parametro @TableName com os testes numero 2, 3 e4 e para os parametros @TS ColumnName e @TS RowVersion com os testesnumero 5, 6 e 7 da tabela de testes para este procedimento.

Os parametros @TS ColumnName e @TS RowVersion foram considerados emconjunto porque sao ambos necessarios para obter alteracoes apos umadeterminada marca temporal nao fazendo sentido testa-los de forma independente.

59. O caso de teste e: obter o JSON formatado com as alteracoes capturadas comtodos os parametros a NULL.

• Pretende testar-se se o procedimento funciona fornecendo-lhe todos osargumentos a NULL.

• Os parametros de entrada sao cinco sequencias de caracteres:

– a NULL.


– a NULL.


60. O caso de teste e: obter o JSON formatado com as alteracoes capturadas apenascom o nome das tabelas do conector.

• Pretende testar-se se o procedimento funciona fornecendo-lhe apenas o nomeda tabela de configuracao e da tabela auxiliar de registo de tabelas.


Tabela 14: Resultados dos testes de caixa preta ao procedimento usp MakeJSON


testeNum. do teste (@RetJSON) (@RetJSON)


4

({”records”:[{”value”:{ ({”records”:[{”value”:{”databaseID”: ”LearningCDC”, ”databaseID”: ”LearningCDC”,”eventID”: ”5447B34E-69E9- ”eventID”: ”5447B34E-69E9-

4542-ABB6-427D3C1ECCC7”, 4542-ABB6-427D3C1ECCC7”,”eventSeq”: 162967, ”eventSeq”: 162967,

”eventTS”: ”2017-05-02T17:38:42”, ”eventTS”: ”2017-05-02T17:38:42”,”eventType”: ”OBJ CHANGE”, ”eventType”: ”OBJ CHANGE”,

”transactionID”: ”343284”, ”transactionID”: ”343284”,”tables”:[{”table”:”Employee”, ”tables”:[{”table”:”Employee”,

”operations”:”INSERT”, ”operations”:”INSERT”,”seq”:1,”rows”:[{ ”seq”:1,”rows”:[{

”rowid”:”00000059000060A10003”, ”rowid”: ”00000059000060A10003”,”seq”:1,”operations”:”INSERT”, ”seq”:1,”operations”: ”INSERT”,”data”:[{”col”:”EmployeeID”, ”data”: [{”col”:”EmployeeID”,


”type”:”String”}]}’) ”type”:”String”}]}’)5 (NULL) (NULL)6 (NULL) (NULL)

7








”type”:”String”}, ”type”:”String”},{”col”:”LastAlterations”, {”col”:”LastAlterations”,

”val”:”11:52:32 08-02-2017”, ”val”:”11:52:32 08-02-2017”,”type”:”Timestamp”}]}]}]}}]}’) ”type”:”Timestamp”}]}]}]}}]}’)




– uma com o nome da tabela auxiliar de registo de tabelas.

– tres a NULL.


– a NULL.


61. O caso de teste e: obter o JSON formatado com as alteracoes capturadas de umatabela com o nome vazio.

• Pretende testar-se se o procedimento funciona fornecendo-lhe o nome deuma tabela vazia para capturar alteracoes.




– uma com o nome da tabela para capturar alteracoes vazia.

– duas a NULL.


– a NULL.


62. O caso de teste e: obter o JSON formatado com as alteracoes capturadas de umatabela.

• Pretende testar-se se o procedimento funciona fornecendo-lhe o nome deuma tabela para capturar alteracoes.





– duas a NULL.


– {"records":[{"value":{"databaseID":"LearningCDC","eventID":"5447B34E-69E9-4542-ABB6-427D3C1ECCC7",

"eventSeq":162967,"eventTS":"2017-05-02T17:38:42",


"eventType":"OBJ -

CHANGE","transactionID":"343284",

"tables":[{"table":"Employee","operations":"INSERT","seq":1,"rows":[{"rowid":"00000059000060A10003","seq":1,"operations":

"INSERT","data":[{"col":"EmployeeID","val":"9079","type":"Decimal"},{"col":"Name","val":"Carl Peterson","type":"String"}]}]}]}}]}’

• O resultado obtido e uma sequencia de caracteres:



"eventType":"OBJ -




63. O caso de teste e: obter o JSON formatado com as alteracoes capturadas de umatabela sem fornecer o nome da tabela auxiliar de registo nem uma marca temporal.

• Pretende testar-se se o procedimento captura as ultimas alteracoes de umatabela sem fornecer uma marca temporal.



– uma com o nome da tabela auxiliar de registo de tabelas a NULL.


– duas a NULL.


– a NULL.


64. O caso de teste e: obter o JSON formatado com as alteracoes capturadas de umatabela apos uma marca temporal vazia.

• Pretende testar-se se o procedimento captura alteracoes fornecendo a tabelaauxiliar de registo a NULL e uma marca temporal vazia.






– duas vazias.


– a NULL.


65. O caso de teste e: obter o JSON formatado com as alteracoes capturadas de umatabela apos uma marca temporal.

• Pretende testar-se se o procedimento captura alteracoes de uma tabela aposuma marca temporal fornecida.





– uma com o nome da coluna com as marcas temporais de alteracao daslinhas.

– uma com a marca temporal de referencia para obter alteracoes.




"eventType":"OBJ -



"INSERT","data":[{"col":"EmployeeID","val":"9079","type":"Decimal"},{"col":"Name","val":"Carl Peterson","type":"String"},{"col":"LastAlterations","val":"11:52:32 08-02-2017",

"type":"Timestamp"}]}]}]}}]}’



Testes de caixa branca ao procedimento: usp MakeJSON



• o nome da tabela auxiliar onde o conector regista as tabelas onde devecapturar alteracoes.

• o nome da tabela para registar alteracoes.

• o nome da coluna da tabela onde sao registadas as marcas temporais dealteracao das linhas.

• a marca temporal a partir da qual se pretende obter as alteracoes.

66. O caso de teste e: obter o JSON das ultimas alteracoes de uma tabela inexistente.

• Pretende testar-se se e formatado algum JSON fornecendo o nome de umataela inexistente.


– a NULL.


67. O caso de teste e: obter o JSON das ultimas alteracoes da tabela indicada.

• Pretende formatar-se o JSON com as ultimas alteracoes da tabela indicada.




"eventType":"OBJ -





68. O caso de teste e: obter JSON das linhas alteradas numa tabela apos uma marcatemporal no futuro.


• Pretende obter-se as linhas alteradas na tabela indicada, apos uma marcatemporal (timestamp) no futuro.


– a NULL.


69. O caso de teste e: obter JSON das linhas alteradas numa tabela apos uma marcatemporal no passado.

• Pretende obter-se as linhas alteradas na tabela indicada, apos uma marcatemporal (timestamp) no passado.




"eventType":"OBJ -



"INSERT","data":[{"col":"EmployeeID","val":"9079","type":"Decimal"},{"col":"Name","val":"Carl Peterson","type":"String"},{"col":"LastAlterations","val":"11:52:32 08-02-2017",

"type":"Timestamp"}]}]}]}}]}’


Testes de caixa preta ao procedimento: usp RegisterTableInCDC

O valor de entrada e a seguinte sequencia de caracteres:

• @tableName: o nome da tabela a registar para capturar alteracoes.


• @tableName: NVARCHAR(MAX): NULL, comprimento=0,comprimento=]0,MAX[.


Tabela 15: Plano de testes de caixa preta ao procedimento usp RegisterTableInCDC

Casos de teste Valores de entradaNum. do teste (@tableName)

1 (NULL)2 (”)3 (’Employee’)

Garante-se a RACC para o parametro @ColName com os testes numero 1,2 e 3da tabela de testes para este procedimento.

70. O caso de teste e: registar uma tabela com o nome a NULL para capturaralteracoes.

• Pretende testar-se se o procedimento regista uma tabela com o nome a NULL.


– a NULL.


– zero insercoes na tabela de registo.


71. O caso de teste e: registar uma tabela com o nome vazio para capturar alteracoes.

• Pretende testar-se se o procedimento regista uma tabela com o nome vazio.


– vazia.




72. O caso de teste e: registar uma tabela para capturar alteracoes.

• Pretende testar-se se o procedimento regista uma tabela na tabela auxiliar deregisto do conector.


– com o nome de uma tabela.

• O resultado esperado e:

– uma insercao na tabela de registo.



Testes de caixa branca ao procedimento: usp RegisterTableInCDC


• o nome da tabela a registar no conector para capturar alteracoes.

73. O caso de teste e: registar uma tabela inexistente para capturar alteracoes.

• Pretende verificar-se se o procedimento regista uma tabela inexistente natabela auxiliar de registo deste conector.




74. O caso de teste e: registar uma tabela existente para capturar alteracoes.

• Pretende registar-se a tabela indicada na tabela auxiliar de registo desteconector.


– uma insercao na tabela de registo.


75. O caso de teste e: registar uma tabela previamente monitorizada pelo mecanismoCDC.

• Pretende verificar-se se o procedimento regista uma tabela previamenteregistada.


– uma remocao e uma adicao na tabela de registo.

– a remocao de todas as alteracoes detetadas na tabela indicada.


Testes de caixa preta ao procedimento:usp SendJSONByHTTPWithSQLCLR



• @CDCTableRegistryName: o nome da tabela auxiliar de registo de tabelas.



• @TS ColumnName: o nome da coluna com as marcas temporais dealteracao das linhas.

• @TS RowVersion: a marca temporal de referencia para obter as linhasalteradas.

As classes de equivalencia sao iguais para todos os parametros:


Tabela 16: Plano de testes de caixa preta ao procedimento usp SendJ-SONByHTTPWithSQLCLR


Num. do teste(@ConfigCDCTableName, @CDCTab leRegistryName,@TableName, @TS ColumnName, @TS RowVersion)

1 (NULL, NULL, NULL, NULL, NULL)


NULL, NULL, NULL)


”, NULL, NULL)


’Employee’, NULL, NULL)

5(’ConfigCDCTable’, NULL,’Employee’, NULL, NULL)


’Employee’, ”, ”)


’Employee’, ’LastAlteration’, ’11:52:32 08-02-2017’)

Garante-se a RACC para o parametro @TableName com os testes numero 2, 3 e4 e para os parametros @TS ColumnName e @TS RowVersion com os testesnumero 5, 6 e 7 da tabela de testes para este procedimento.

Os parametros @TS ColumnName e @TS RowVersion foram considerados emconjunto porque sao ambos necessarios para obter alteracoes apos umadeterminada marca temporal nao fazendo sentido testa-los de forma independente.

76. O caso de teste e: publicar o JSON formatado com as alteracoes capturadas comtodos os parametros a NULL.

• Pretende testar-se se o procedimento publica alteracoes fornecendo-lhe todosos argumentos a NULL.



– ambas a NULL.

• O resultado esperado e o envio de:

– zero sequencias de caracteres.


77. O caso de teste e: publicar o JSON formatado com as alteracoes capturadas apenascom o nome das tabelas do conector.

• Pretende testar-se se o procedimento publica alteracoes fornecendo-lheapenas o nome da tabela de configuracao e da tabela auxiliar de registo detabelas.




– tres a NULL.




78. O caso de teste e: publicar o JSON formatado com as alteracoes capturadas deuma tabela com o nome vazio.

• Pretende testar-se se o procedimento publica alteracoes fornecendo-lhe onome de uma tabela vazia para capturar alteracoes.




– uma com o nome da tabela para capturar alteracoes vazia.

– duas a NULL.




79. O caso de teste e: publicar o JSON formatado com as alteracoes capturadas deuma tabela.


• Pretende testar-se se o procedimento publica alteracoes fornecendo-lhe onome de uma tabela para capturar alteracoes.





– duas a NULL.


– uma sequencia de caracteres com as alteracoes em formato JSON.


80. O caso de teste e: publicar o JSON formatado com as alteracoes capturadas de umatabela sem fornecer o nome da tabela auxiliar de registo nem uma marca temporal.

• Pretende testar-se se o procedimento publica as ultimas alteracoes de umatabela sem fornecer uma marca temporal.





– duas a NULL.




81. O caso de teste e: publicar o JSON formatado com as alteracoes capturadas deuma tabela apos uma marca temporal vazia.

• Pretende testar-se se o procedimento publica alteracoes fornecendo a tabelaauxiliar de registo a NULL e uma marca temporal vazia.





– duas vazias.





82. O caso de teste e: publicar o JSON formatado com as alteracoes capturadas deuma tabela apos uma marca temporal.

• Pretende testar-se se o procedimento publica alteracoes de uma tabela aposuma marca temporal fornecida.





– uma com o nome da coluna com as marcas temporais de alteracao daslinhas.

– uma com a marca temporal de referencia para obter alteracoes.


– uma sequencia de caracteres com as alteracoes em formato JSON.


Testes de caixa branca ao procedimento:usp SendJSONByHTTPWithSQLCLR

83. O caso de teste e: obter e enviar o JSON de todas as alteracoes detetadas pelomecanismo CDC.

• Pretende enviar-se o JSON com as alteracoes detetadas desde o ultimo enviobem sucedido e em seguida elimina o registo das alteracoes incluıdas noJSON.


– o envio de uma sequencia de caracteres com as alteracoes.

– a eliminacao das alteracoes enviadas.


84. O caso de teste e: obter e enviar o JSON com as linhas alteradas de uma tabelainexistente.

• Pretende verificar-se se o procedimento envia o JSON com as linhas alteradasde uma tabela inexistente.





85. O caso de teste e: obter e enviar o JSON com as linhas alteradas de uma tabelafornecendo uma marca temporal no futuro.

• Pretende verificar-se se o procedimento envia o JSON com as linhas alteradasde uma tabela considerando uma marca temporal no futuro.




86. O caso de teste e: obter e enviar o JSON com as linhas alteradas de uma tabelaapos uma marca temporal (timestamp) no passado.

• Pretende enviar-se o JSON com as linhas alteradas desde uma marcatemporal no passado, usando como referencia a coluna indicada.


– o envio de uma sequencia de caracteres com as alteracoes.

– a eliminacao das alteracoes enviadas.


Testes de caixa branca ao procedimento: usp StartGetCDCAlterations

87. O caso de teste e: definir um novo agendamento para enviar periodicamente oJSON com todas as alteracoes registadas pelo mecanismo CDC.

• Pretende definir-se o agendamento para enviar o JSON com as alteracoesregistadas.


– um agendamento ativo que envie as alteracoes periodicamente.


88. O caso de teste e: redefinir o agendamento existente para enviar o JSON com asalteracoes registadas pelo mecanismo CDC.

• Pretende verificar-se o funcionamento do procedimento quando ja esta umagendamento ativo.



– o cancelamento do agendamento ativo.

– a definicao de um novo agendamento utilizando os parametros atuais databela de configuracao.


Testes de caixa branca ao procedimento: usp SyncAllCDCTables

89. O caso de teste e: sincronizar todas as tabelas sem existirem alteracoes.

• Pretende testar-se se o procedimento altera alguma tabela se nao foremrealizadas alteracoes.


– zero alteracoes nas tabelas.


90. O caso de teste e: sincronizar todas as tabelas apos adicionar uma nova coluna.

• Pretende testar-se se o procedimento atualiza o mecanismo de captura dedados quando se adiciona uma nova coluna a uma tabela.


– a adicao de uma nova coluna na tabela de registo de alteracoes.


91. O caso de teste e: sincronizar todas as tabelas apos alterar o tipo de uma coluna.

• Pretende testar-se se o procedimento atualiza o mecanismo de captura dedados quando se altera o tipo de uma coluna numa tabela.


– a atualizacao do tipo da coluna alterada.


92. O caso de teste e: sincronizar todas as tabelas apos apagar uma coluna.

• Pretende testar-se se o procedimento atualiza o mecanismo de captura dedados quando se apaga uma coluna numa tabela.


– a eliminacao da coluna removida.



Testes de caixa preta ao procedimento: usp SyncCDCTable


• @TableName: o nome da tabela para sincronizar.


• @TableName: NVARCHAR(MAX): NULL, comprimento=0,comprimento=]0,MAX[.

Tabela 17: Plano de testes de caixa preta ao procedimento usp SyncCDCTable

Casos de teste Valores de entradaNum. do teste (@TableName)


Garante-se a RACC para o parametro @TableName com os testes numero 1, 2 e3 da tabela de testes para este procedimento.

93. O caso de teste e: sincronizar uma tabela com o nome a NULL.

• Pretende testar-se se o procedimento funciona quando o nome da tabela eNULL.


– a NULL.


– nenhuma tabela alterada.


94. O caso de teste e: sincronizar uma tabela com o nome vazio.

• Pretende testar-se se o procedimento funciona quando o nome da tabela estavazio.


– vazia.





95. O caso de teste e: sincronizar uma tabela alterada.

• Pretende testar-se se o procedimento sincroniza a tabela alterada indicada.


– com o nome da tabela a sincronizar.


– a atualizacao da tabela de captura de alteracoes para refletir asincronizada.


Testes de caixa branca ao procedimento: usp SyncCDCTable

O parametro de entrada e uma sequencia de caracteres com:

• o nome da tabela para sincronizar.

96. O caso de teste e: sincronizar uma tabela inexistente.

• Pretende verificar-se se o procedimento altera alguma tabela quandosincroniza uma tabela inexistente.




97. O caso de teste e: sincronizar uma tabela onde se adicionou uma coluna.

• Pretende verificar-se se tambem e adicionada uma coluna a tabela de registode alteracoes.


– a adicao de uma coluna a tabela de registo de alteracoes.


98. O caso de teste e: sincronizar uma tabela onde se alterou o tipo de uma coluna.

• Pretende verificar-se se tambem e alterado o tipo de uma coluna na tabela deregisto de alteracoes.


– a alteracao do tipo de uma coluna na tabela de registo de alteracoes.



99. O caso de teste e: sincronizar uma tabela onde se eliminou uma coluna.

• Pretende verificar-se se tambem e eliminada uma coluna na tabela de registode alteracoes.


– a remocao de uma coluna na tabela de registo de alteracoes.


100. O caso de teste e: sincronizar uma tabela nao alterada.

• Pretende verificar-se se o procedimento altera alguma tabela quandosincroniza uma tabela nao alterada.




101. O caso de teste e: sincronizar uma tabela nao monitorizada pelo mecanismo CDC.

• Pretende verificar-se se o procedimento altera alguma tabela quando sesincroniza uma tabela nao registada.




Testes de caixa preta ao procedimento: usp UnregisterTableInCDC

O valor de entrada e a seguinte sequencia de caracteres:

• @tableName: o nome da tabela para cancelar o registo.


• @tableName: NVARCHAR(MAX): NULL, comprimento=0,comprimento=]0,MAX[.


Tabela 18: Plano de testes de caixa preta ao procedimento usp UnregisterTableInCDC

Casos de teste Valores de entradaNum. do teste ( @tableName)


Garante-se a RACC para o parametro @tableName com os testes numero 1, 2 e3 da tabela de testes para este procedimento.

102. O caso de teste e: cancelar o registo de uma tabela com o nome a NULL.

• Pretende testar-se se o procedimento cancela o registo de uma tabela com onome a NULL.


– a NULL.


– nenhum registo cancelado.


103. O caso de teste e: cancelar o registo de uma tabela com o nome vazio.

• Pretende testar-se se o procedimento cancela o registo de uma tabela com onome vazio.


– vazia.


– Nenhum registo cancelado.


104. O caso de teste e: cancelar o registo de uma tabela registada.

• Pretende testar-se se o procedimento cancela o registo de uma tabelaregistada.


– com o nome de uma tabela registada.


– o cancelamento do registo da tabela.



Testes de caixa branca ao procedimento: usp UnregisterTableInCDC


• o nome da tabela para cancelar o registo.

105. O caso de teste e: cancelar o registo de uma tabela inexistente.

• Pretende verificar-se se o procedimento altera algum registo quando secancela o registo de uma tabela inexistente.




106. O caso de teste e: cancelar o registo de uma tabela nao registada.

• Pretende verificar-se se o procedimento altera algum registo quando secancela o registo de uma tabela nao registada.





• Pretende verificar-se se o procedimento cancela o registo de uma tabelaregistada.





Testes de caixa branca ao procedimento: usp InstalationScriptDBA

108. O caso de teste e: configurar a BD, criar utilizadores e atribuir-lhes permissoes.

• Pretende verificar-se se o procedimento configura a BD e os utilizadores.


– a ativacao do mecanismo CDC na BD.

– a criacao dos utilizadores CDC admin e CDC user.


– a atribuicao de permissoes a estes utilizadores para executarem osprocedimentos e funcoes necessarias para o funcionamento do conector.


109. O caso de teste e: configurar a BD e atribuir permissoes a utilizadorespre-existentes.

• Pretende verificar-se se o procedimento configura a BD e atribui permissoesquando nao pode criar novos utilizadores.


– a ativacao do mecanismo CDC na BD.

– a atribuicao de permissoes aos utilizadores existentes para executarem osprocedimentos e funcoes necessarias para o funcionamento do conector.


110. O caso de teste e: configurar uma BD pre-configurada e atribuir permissoes autilizadores pre-existentes.

• Pretende verificar-se se o procedimento configura uma BD em utilizacao eatribui permissoes quando nao pode criar novos utilizadores.


– a reconfiguracao do mecanismo CDC na BD.

– a atribuicao de permissoes aos utilizadores existentes para executarem osprocedimentos e funcoes necessarias para o funcionamento do conector.


Testes de caixa branca ao procedimento: usp InstalationScriptAdminCDC

111. O caso de teste e: criar os procedimentos, a tabela de configuracao e a tabelaauxiliar de registo do conector.

• Pretende criar-se os procedimentos, a tabela de configuracao e a tabelaauxiliar de registo e inicializa-las com os valores pre-definidos.


– a criacao dos procedimentos, da tabela de configuracao e da tabelaauxiliar de registo do conector.

– a inicializacao das tabelas com os valores pre-definidos.



112. O caso de teste e: criar os procedimentos, a tabela de configuracao e a tabelaauxiliar de registo do conector quando estes ja existem.

• Pretende verificar-se a inicializacao do conector quando esta ja tinha sidorealizada anteriormente.


– a eliminacao dos procedimentos, da tabela de configuracao e da tabelaauxiliar pre-existentes.

– a criacao dos procedimentos, da tabela de configuracao e da tabelaauxiliar de registo do conector.

– a inicializacao das tabelas com os valores pre-definidos.


.1.2 Testes unitarios ao conector MySQLTestes de caixa preta a funcao: readConfigFile


• configFilename: o nome do ficheiro de configuracao do conector.


• configFilename: NVARCHAR(MAX): NULL, comprimento=0,comprimento=]0,MAX[.

Tabela 19: Plano de testes de caixa preta a funcao readConfigFile

Casos de teste Valores de entradaNum. do teste (configFilename)

1 (NULL)2 (”)3 (’configfile.cfg’)

Garante-se a RACC para o parametro configFilename com os testes numero 1, 2 e 3da tabela de testes para este procedimento.

1. O caso de teste e: ler o ficheiro de configuracao do conector com o nome a NULL.

• Pretende testar-se se a funcao le o ficheiro de configuracao quando o nomefornecido e NULL.



Tabela 20: Resultados dos testes de caixa preta a funcao readConfigFile


testeNum. do teste (server, user, password, database) (server, user, password, database)

1 (NULL,NULL,NULL,NULL) (NULL,NULL,NULL,NULL)2 (NULL,NULL,NULL,NULL) (NULL,NULL,NULL,NULL)

3(’localhost’,’root’, (’localhost’,’root’,

’pass’,’learningcdc’) ’pass’,’learningcdc’)

– a NULL.

• Os resultados esperados sao quatro sequencias de caracteres:

– todas a NULL.


2. O caso de teste e: ler o ficheiro de configuracao do conector com o nome vazio.

• Pretende testar-se se a funcao le o ficheiro de configuracao quando o nomefornecido e vazio.


– vazia.


– todas a NULL.


3. O caso de teste e: ler o ficheiro de configuracao do conector indicado.

• Pretende testar-se se a funcao le o ficheiro de configuracao do conectorquando se lhe fornece o nome.


– com o nome do ficheiro de configuracao.


– uma com o nome do servidor.

– uma com o nome de utilizador.

– uma com a password.

– uma com o nome da base de dados.



Testes de caixa branca a funcao: readConfigFile


• o nome do ficheiro de configuracao do conector.

4. O caso de teste e: ler um ficheiro de configuracao do conector inexistente.

• Pretende verificar-se se a funcao le os valores de configuracao de um ficheiroinexistente.


– todas a NULL.


5. O caso de teste e: ler um ficheiro de configuracao do conector vazio.

• Pretende verificar-se se a funcao le os valores de configuracao de um ficheirovazio.


– todas a NULL.


6. O caso de teste e: ler um ficheiro de configuracao do conector existente.

• Pretende verificar-se se a funcao le os valores de configuracao de um ficheiroexistente.


– uma com o nome do servidor.

– uma com o nome de utilizador.

– uma com a password.

– uma com o nome da base de dados.


Testes de caixa preta a funcao: getLastClosedProcLogFile

Os valores de entrada sao:

• schema: uma sequencia de caracteres com o nome da base de dados emutilizacao.

• conn: uma estrutura que representa a ligacao a base de dados.



• schema: char*: NULL, comprimento=0, comprimento=]0,MAX[.

• conn: MYSQL: NULL, ativa.

Tabela 21: Plano de testes de caixa preta a funcao getLastClosedProcLogFile

Casos de teste Valores de entradaNum. do teste (schema, conn)

1 (NULL, NULL)2 (NULL, ativa)3 (”, ativa)4 (’learningcdc’, ativa)

Tabela 22: Resultados dos testes de caixa preta a funcao getLastClosedProcLogFile


testeNum. do teste (processedFilename) (processedFilename)

1 (NULL) (NULL)2 (NULL) (NULL)3 (NULL) (NULL)4 (’procivosilva-bin.000382’) (’procivosilva-bin.000382’)

Garante-se a RACC para o parametro processedFileName com os testes numero2, 3 e 4 da tabela de testes para este procedimento.

7. O caso de teste e: obter o nome do ficheiro de registo de alteracoes processadosem fornecer argumentos.


• Os parametros de entrada sao:

– uma sequencia de caracteres a NULL.

– uma estrutura que representa uma ligacao a BD a NULL.


– a NULL.


8. O caso de teste e: obter o nome do ficheiro de registo de alteracoes processadosem fornecer o nome da BD.


• Pretende testar-se se o procedimento funciona fornecendo o nome da BD aNULL.



– uma estrutura que representa uma ligacao ativa a BD.


– a NULL.


9. O caso de teste e: obter o nome do ficheiro de registo de alteracoes processadofornecendo o nome da BD vazio.

• Pretende testar-se se o procedimento funciona fornecendo o nome da BDvazio.


– uma sequencia de caracteres vazia.



– a NULL.


10. O caso de teste e: obter o nome do ficheiro de registo de alteracoes processadofornecendo o nome da BD em utilizacao.

• Pretende testar-se se o procedimento funciona fornecendo o nome da BD emutilizacao.


– uma sequencia de caracteres com o nome da BD em utilizacao.



– com o nome do ficheiro de registo de alteracoes processado.


Testes de caixa branca a funcao: getLastClosedProcLogFile

Os parametros de entrada sao:


• uma sequencia de caracteres com o nome da BD em utilizacao.

• uma estrutura que representa uma ligacao ativa a BD.

11. O caso de teste e: obter o nome do ficheiro de registo de alteracoes processadoquando nao e possıvel aceder a BD.

• Pretende verificar-se se a funcao disponibiliza o nome do ficheiro de registode alteracoes processado quando se fornece uma ligacao inactiva a BD.


– a NULL.


12. O caso de teste e: obter o nome do ficheiro de registo de alteracoes processadofornecendo o nome de uma BD inexistente.

• Pretende verificar-se se a funcao disponibiliza o nome do ficheiro de registode alteracoes processado quando se fornece o nome de uma BD inexistente.


– a NULL.


13. O caso de teste e: obter o nome do ficheiro de registo de alteracoes processadofornecendo o nome da BD em utilizacao.

• Pretende verificar-se se a funcao disponibiliza o nome do ficheiro de registode alteracoes processado quando se fornece o nome da BD em utilizacao.


– com o nome do ficheiro de registo de alteracoes processado.


Testes de caixa preta a funcao: readLastClosedLogFile


• processedFilename: uma sequencia de caracteres com o nome do ficheiro deregisto de alteracoes processado.

• logPosition: uma sequencia de caracteres com a ultima posicao do ficheiroincluıda no JSON.

• tsValue: uma sequencia de caracteres com a marca temporal da ultimaalteracao incluıda no JSON.


• conn: uma estrutura que representa uma ligacao ativa a BD.


• processedFilename: NVARCHAR(MAX) NULL, comprimento=0,comprimento=]0,MAX[.

• logPosition: NVARCHAR(MAX) NULL, comprimento=0,comprimento=]0,MAX[.

• tsValue: NVARCHAR(MAX) NULL, comprimento=0,comprimento=]0,MAX[.


Tabela 23: Plano de testes de caixa preta a funcao readLastClosedLogFile

Casos de teste Valores de entradaNum. do teste (processedFilename, logPosition, tsValue, conn)

1 (NULL, NULL, NULL, NULL)2 (NULL, ’1’, ’11:52:32 08-02-2017’, ativa)3 (”, ’1’, ’11:52:32 08-02-2017’, ativa)4 (’procivosilva-bin.000382’, ’1’, ’11:52:32 08-02-2017’, ativa)

Garante-se a RACC para o parametro processedFileName com os testes numero2, 3 e 4 da tabela de testes para este procedimento.

14. O caso de teste e: ler o ultimo ficheiro de registo fechado sem parametros.

• Pretende testar-se se o procedimento funciona fornecendo-lhe todos osparametros a NULL.

• Os parametros de entrada sao quatro sequencias de caracteres:

– todas a NULL.


– a NULL.


15. O caso de teste e: ler o ultimo ficheiro de registo fechado sem fornecer o nome doficheiro.

• Pretende testar-se se o procedimento funciona sem lhe fornecer o nome doficheiro.



Tabela 24: Resultados dos testes de caixa preta a funcao readLastClosedLogFile


testeNum. do teste (rowJSON) (rowJSON)


4









– uma com o nome do ficheiro processado a NULL.

– uma com a ultima posicao do registo incluıda no JSON.

– uma com a ultima marca temporal incluıda no JSON.

– uma com a estrutura que representa a ligacao a BD.


– a NULL.

• O resultado obtido e uma sequencia de caracteres:

– a NULL.

16. O caso de teste e: ler o ultimo ficheiro de registo fechado com o nome do ficheirovazio.

• Pretende testar-se se o procedimento le algum ficheiro de registo quando efornecido um nome vazio.



– uma com o nome do ficheiro processado vazio.





– a NULL.


17. O caso de teste e: ler o ultimo ficheiro de registo fechado fornecendo o seu nome.

• Pretende testar-se se o procedimento le o ultimo ficheiro de registo fechadoquando se fornece o seu nome.


– uma com o nome do ultimo ficheiro de registo processado.





– (’{"records":[{"value":{"databaseID":"LearningCDC",

"eventID":"5447B34E-69E9-4542-

ABB6-427D3C1ECCC7",

"eventSeq":162967,

"eventTS":"2017-05-02T17:38:42",

eventType":"OBJ CHANGE",

"transactionID":"343284",

"tables":[{"table":"Employee","operations":"INSERT", "seq":1,"rows":[{"rowid":"00000059000060A10003",

"seq":1,"operations":"INSERT","data":[{"col":"EmployeeID","val":"9079",

"type":"Decimal"},{"col":"Name","val":"Carl Peterson","type":"String"}]}’)


Testes de caixa branca a funcao: readLastClosedLogFile



• uma sequencia de caracteres com o nome do ficheiro de registo de alteracoesprocessado.

• uma sequencia de caracteres com a ultima posicao do ficheiro incluıda noJSON.

• uma sequencia de caracteres com a marca temporal da ultima alteracaoincluıda no JSON.


18. O caso de teste e: ler um ficheiro de registo de alteracoes fornecendo o nome deum ficheiro inexistente.

• Pretende verificar-se se a funcao le algum ficheiro de log quando o nomeindicado nao corresponde a nenhum ficheiro.


– a NULL.


19. O caso de teste e: ler um ficheiro de registo de alteracoes fornecendo uma posicaosuperior a ultima utilizada.

• Pretende verificar-se se a funcao le o ficheiro de log quando a ultima posicaoindicada e maior do que a ultima posicao existente no ficheiro.


– a NULL.


20. O caso de teste e: ler um ficheiro de registo de alteracoes fornecendo uma posicaoanterior as incluıdas no ficheiro.

• Pretende verificar-se se a funcao le o ficheiro de log quando a ultima posicaoindicada e anterior as existentes no ficheiro.



"eventID":"5447B34E-69E9-4542-

ABB6-427D3C1ECCC7",

"eventSeq":162967,

"eventTS":"2017-05-02T17:38:42",






"type":"Decimal"},{"col":"Name","val":"Carl Peterson","type":"String"}]}’)


21. O caso de teste e: ler um ficheiro de registo de alteracoes fornecendo uma marcatemporal no futuro.

• Pretende verificar-se se a funcao le o ficheiro de log quando a marca temporalda ultima alteracao incluıda no JSON e no futuro.


– a NULL.


22. O caso de teste e: ler um ficheiro de registo de alteracoes fornecendo uma marcatemporal anterior as alteracoes presentes no ficheiro.

• Pretende verificar-se se a funcao le o ficheiro de log quando a marca temporalda ultima alteracao incluıda no JSON e anterior as alteracoes registadas noficheiro.



"eventID":"5447B34E-69E9-4542-

ABB6-427D3C1ECCC7",

"eventSeq":162967,

"eventTS":"2017-05-02T17:38:42",





"type":"Decimal"},{"col":"Name",


"val":"Carl Peterson","type":"String"}]}’)


Testes de caixa preta a funcao: updateLogPosition


• configSchema: uma sequencia de caracteres com o nome da BD onde esta atabela de configuracao.

• position: uma sequencia de caracteres com a nova posicao.



• configSchema: NVARCHAR(MAX) NULL, comprimento=0,comprimento=]0,MAX[.

• position: NVARCHAR(MAX) NULL, comprimento=0,comprimento=]0,MAX[.


Tabela 25: Plano de testes de caixa preta a funcao updateLogPosition

Casos de teste Valores de entradaNum. do teste (configSchema, position, conn)

1 (NULL, NULL, NULL)2 (’learningcdc’, NULL, ativa)3 (’learningcdc’, ”, ativa)4 (’learningcdc’, ’277’, ativa)

Garante-se a RACC para o parametro position com os testes numero 2, 3 e 4 databela de testes para este procedimento.

23. O caso de teste e: atualizar na tabela de configuracao a ultima posicao lida doregisto de alteracoes com todos os parametros a NULL:

• Pretende testar-se se a funcao atualiza a ultima posicao lida do registo dealteracoes quando todos os argumentos sao passados a NULL.


– duas sequencias de caracteres a NULL.

– uma estrutura a NULL.



– zero alteracoes na tabela de configuracao.


24. O caso de teste e: atualizar na tabela de configuracao a ultima posicao lida doregisto de alteracoes sem a indicar.

• Pretende testar-se se a funcao atualiza a ultima posicao lida do registo dealteracoes quando esta e passada a NULL.


– uma sequencia de caracteres com o nome da BD.






25. O caso de teste e: atualizar na tabela de configuracao a ultima posicao lida doregisto de alteracoes indicando uma posicao vazia.

• Pretende testar-se se a funcao atualiza a ultima posicao lida do registo dealteracoes quando a sequencia de caracteres passada esta vazia.








26. O caso de teste e: atualizar na tabela de configuracao a ultima posicao lida doregisto de alteracoes.

• Pretende testar-se se a funcao atualiza a ultima posicao lida do ficheiroprocessado de registo de alteracoes.




– uma sequencia de caracteres com a ultima posicao lida do ficheiro.



– uma atualizacao a linha com a ultima posicao na tabela de configuracao.


Testes de caixa branca a funcao: updateLogPosition


• uma sequencia de caracteres com o nome da BD da tabela de configuracao.

• uma sequencia de caracteres com a ultima posicao lida do registo dealteracoes.


27. O caso de teste e: atualizar a ultima posicao lida do registo numa BD inexistente.

• Pretende verificar-se se a funcao atualiza a ultima posicao lida numa tabelade configuracao de uma BD inexistente.




28. O caso de teste e: atualizar a ultima posicao lida do registo numa BD sem a tabelade configuracao do conector.

• Pretende verificar-se se a funcao atualiza a ultima posicao lida quando naoexiste tabela de configuracao do conector.




29. O caso de teste e: atualizar a ultima posicao lida do registo com um valor negativo.

• Pretende verificar-se se a funcao atualiza a ultima posicao lida com um valornegativo.



• O resultado obtido e:


– uma alteracao na ultima posicao lida registada na tabela de configuracao.

30. O caso de teste e: atualizar a ultima posicao lida do registo com um valor superiorao ultimo registado.

• Pretende verificar-se se a funcao atualiza a ultima posicao lida com um valorsuperior ao registado na ultima alteracao do registo mais atual.




– uma alteracao na ultima posicao lida registada na tabela de configuracao.

31. O caso de teste e: atualizar a ultima posicao lida do registo com o ultimo valor lido.

• Pretende verificar-se se a funcao atualiza a ultima posicao lida registada natabela de configuracao com o ultimo valor lido.


– uma atualizacao da ultima posicao lida registada na tabela deconfiguracao.


Testes de caixa preta a funcao: updateTimestamp


• configSchema: uma sequencia de caracteres com o nome da BD onde esta atabela de configuracao.

• timestamp: uma sequencia de caracteres com a marca temporal da ultimaalteracao lida do registo de alteracoes.



• configSchema: char*: NULL, comprimento=0, comprimento=]0,MAX[.

• timestamp: char*: NULL, comprimento=0, comprimento=]0,MAX[.



Tabela 26: Plano de testes de caixa preta a funcao getTimestamp

Casos de teste Valores de entradaNum. do teste (configSchema, timestamp, conn)

1 (NULL, NULL, NULL)2 (’learningcdc’, NULL , ativa)3 (’learningcdc’, ”, ativa)4 (’learningcdc’, ’11:52:32 08-02-2017’, ativa)

Garante-se a RACC para o parametro timestamp com os testes numero 2, 3 e 4da tabela de testes para este procedimento.

32. O caso de teste e: atualizar na tabela de configuracao a marca temporal da ultimaleitura do registo de alteracoes sem fornecer parametros.

• Pretende testar-se se a funcao atualiza a marca temporal da ultima leitura doregisto de alteracoes quando todos os argumentos sao passados a NULL.


– duas sequencias de caracteres a NULL.

– uma estrutura a NULL.




33. O caso de teste e: atualizar na tabela de configuracao a marca temporal da ultimaleitura do registo de alteracoes sem fornecer a marca temporal.

• Pretende testar-se se a funcao atualiza a marca temporal da ultima leitura doregisto de alteracoes quando esta e passada a NULL.


– uma sequencia de caracteres com o nome da BD onde esta a tabela deconfiguracao.






34. O caso de teste e: atualizar na tabela de configuracao a marca temporal da ultimaleitura do registo de alteracoes fornecendo uma marca temporal vazia.


• Pretende testar-se se a funcao atualiza a marca temporal da ultima leitura doregisto de alteracoes quando esta e fornecida vazia.








35. O caso de teste e: atualizar na tabela de configuracao a marca temporal da ultimaleitura do registo de alteracoes fornecendo-a como parametro.

• Pretende testar-se se a funcao atualiza a marca temporal da ultima leitura doregisto de alteracoes quando esta e fornecida.



– uma sequencia de caracteres com a marca temporal da ultima leitura doregisto de alteracoes.



– uma atualizacao na tabela de configuracao da marca temporal da ultimaleitura registada.


Testes de caixa branca a funcao: updateTimestamp


• uma sequencia de caracteres com o nome da BD onde esta a tabela deconfiguracao.

• uma sequencia de caracteres com a marca temporal da ultima leitura doregisto de alteracoes.



36. O caso de teste e: atualizar a marca temporal da ultima leitura do registo dealteracoes numa BD inexistente.

• Pretende verificar-se se a funcao atualiza a marca temporal na tabela deconfiguracao de uma BD inexistente.




37. O caso de teste e: atualizar a marca temporal da ultima leitura do registo dealteracoes numa BD sem a tabela de configuracao.

• Pretende verificar-se se a funcao atualiza a marca temporal quando a tabelade configuracao nao existe na BD fornecida.




38. O caso de teste e: atualizar a marca temporal da ultima leitura do registo dealteracoes com uma data no futuro.

• Pretende verificar-se se a funcao atualiza a marca temporal na tabela deconfiguracao com uma data no futuro.




– uma alteracao na marca temporal da ultima leitura do registo persistidana tabela de configuracao.

39. O caso de teste e: atualizar a marca temporal da ultima leitura do registo dealteracoes com a data associada a ultima alteracao processada.

• Pretende verificar-se se a funcao atualiza a marca temporal na tabela deconfiguracao com uma data no passado correspondente a ultima alteracaoincluıda no JSON.


– uma alteracao na marca temporal da ultima leitura do registo persistidana tabela de configuracao.



Testes de caixa preta a funcao: searchForAlterationsInOpenLogFile


• schema: uma sequencia de caracteres com o nome da BD onde esta a tabelade configuracao do conector.



• schema: char*: NULL, comprimento=0, comprimento=]0,MAX[.


Tabela 27: Plano de testes de caixa preta a funcao searchForAlterationsInOpenLogFile

Casos de teste Valores de entradaNum. do teste (schema, conn)

1 (NULL, NULL)2 (NULL, ativa)3 (”, ativa)4 (’learningcdc’, ativa)

Garante-se a RACC para o parametro schema com os testes numero 2, 3 e 4 databela de testes para este procedimento.

40. O caso de teste e: pesquisar novas alteracoes no ficheiro de registo em utilizacaopela BD sem fornecer parametros.

• Pretende testar-se se o procedimento pesquisa novas alteracoes no ficheiro deregisto de alteracoes em utilizacao pela BD quando nao recebe parametros.


– ambas a NULL.


– zero alteracoes encontradas.


41. O caso de teste e: pesquisar novas alteracoes no ficheiro de registo em utilizacaopela BD sem fornecer o nome da BD.

• Pretende testar-se se o procedimento pesquisa novas alteracoes no ficheiro deregisto de alteracoes em utilizacao pela BD quando o nome desta lhe epassado a NULL.








42. O caso de teste e: pesquisar novas alteracoes no ficheiro de registo em utilizacaopela BD com o nome da BD vazio.

• Pretende testar-se se o procedimento pesquisa novas alteracoes no ficheiro deregisto de alteracoes em utilizacao pela BD quando o nome desta lhe efornecido vazio.







43. O caso de teste e: pesquisar novas alteracoes no ficheiro de registo em utilizacaopela BD fornecendo o nome daquela onde esta a tabela de configuracao.

• Pretende testar-se se o procedimento pesquisa novas alteracoes no ficheiro deregisto de alteracoes em utilizacao pela BD quando lhe e indicado o nomedaquela onde esta a tabela de configuracao do conector.





– a detecao das novas alteracoes registadas desde a ultima captura.

– a definicao de um temporizador para acumular mais alteracoes.

– a expiracao do temporizador e o fecho do ficheiro de registo dealteracoes em utilizacao.

– a leitura do ficheiro recem-fechado para obtencao das novas alteracoes.



Testes de caixa branca a funcao: searchForAlterationsInOpenLogFile


• uma sequencia de caracteres com o nome da BD onde esta a tabela deconfiguracao do conector.


44. O caso de teste e: pesquisar novas alteracoes no ficheiro de registo em utilizacaopela BD fornecendo o nome de uma inexistente.

• Pretende verificar-se se a funcao pesquisa novas alteracoes no ficheiro deregisto em utilizacao quando lhe e fornecido o nome de uma BD inexistente.




45. O caso de teste e: pesquisar novas alteracoes no ficheiro de registo em utilizacaopela BD fornecendo o nome de uma onde nao existe tabela de configuracao.

• Pretende verificar-se se a funcao pesquisa novas alteracoes no ficheiro deregisto em utilizacao quando lhe e fornecido o nome de uma BD sem tabelade configuracao do conector.




46. O caso de teste e: pesquisar novas alteracoes no ficheiro de registo em utilizacaopela BD fornecendo o nome da utilizada pelo conector.

• Pretende verificar-se se a funcao pesquisa novas alteracoes no ficheiro deregisto em utilizacao quando lhe e fornecido o nome da BD utilizada peloconector.


– a detecao das novas alteracoes registadas desde a ultima captura.

– a definicao de um temporizador para acumular mais alteracoes.

– a expiracao do temporizador e o fecho do ficheiro de registo dealteracoes em utilizacao.

– a leitura do ficheiro recem-fechado para obtencao das novas alteracoes.



Testes de caixa preta ao procedimento: registerTableInCDC


• schema name: o nome da BD onde esta a tabela.

• table name: o nome da tabela a registar no conector para capturar alteracoes.


• schema name: VARCHAR(40): NULL, comprimento=0,comprimento=]0,MAX[.

• table name: VARCHAR(40): NULL, comprimento=0,comprimento=]0,MAX[.

Tabela 28: Plano de testes de caixa preta ao procedimento registerTableInCDC

Casos de teste Valores de entradaNum. do teste (schema name, table name)

1 (NULL, NULL)2 (’learningcdc’, NULL)3 (’learningcdc’, ”)4 (’learningcdc’, ’Employee’)

Garante-se a RACC para o parametro table name com os testes numero 2, 3 e 4da tabela de testes para este procedimento.

47. O caso de teste e: registar uma tabela no conector para capturar alteracoes semfornecer parametros.

• Pretende testar-se se o procedimento altera a tabela auxiliar de registo doconector quando e executado com todos os parametros a NULL.


– ambas a NULL.


– zero alteracoes na tabela auxiliar de registo do conector.


48. O caso de teste e: registar uma tabela no conector para capturar alteracoes semfornecer o seu nome.

• Pretende testar-se se o procedimento altera a tabela auxiliar de registo doconector quando e indicada uma tabela com o nome a NULL.



– uma com o nome da BD onde esta a tabela a registar.

– uma a NULL.




49. O caso de teste e: registar uma tabela no conector para capturar alteracoesfornecendo o nome vazio.

• Pretende testar-se se o procedimento altera a tabela auxiliar de registo doconector quando e indicada uma tabela com o nome vazio.







50. O caso de teste e: registar uma tabela no conector para capturar alteracoesfornecendo a BD e nome.

• Pretende testar-se se o procedimento utiliza o nome da BD e da tabela para aregistar no conector para este capturar alteracoes.



– uma com o nome da tabela para registar.


– uma adicao de um par com os nomes da BD e da tabela na tabelaauxiliar de registo do conector.


Testes de caixa branca ao procedimento: registerTableInCDC


• o nome da BD onde esta a tabela a registar.


• o nome da tabela para registar.

51. O caso de teste e: registar uma tabela inexistente.

• Pretende verificar-se se o procedimento regista tabelas inexistentes.




– Uma adicao de um par com os nomes da BD e da tabela na tabelaauxiliar de registo do conector.

52. O caso de teste e: registar uma tabela ja registada.

• Pretende verificar-se se o procedimento regista tabelas ja registadas.


– uma remocao de um par com os nomes da BD e da tabela na tabelaauxiliar de registo do conector.



53. O caso de teste e: registar uma tabela nao registada.

• Pretende verificar-se se o procedimento regista tabelas nao registadas.




Testes de caixa preta ao procedimento: unregisterTableInCDC

Os valores de entrada, as classes de equivalencia, o plano de testes e o criteriode cobertura aplicado sao semelhantes aos que foram apresentados anteriormentepara o procedimento registerTableInCDC.

54. O caso de teste e: cancelar o registo de uma tabela no conector sem fornecerparametros.

• Pretende testar-se se o procedimento altera a tabela auxiliar de registo doconector quando e executado com todos os parametros a NULL.



– ambas a NULL.




55. O caso de teste e: cancelar o registo de uma tabela no conector sem fornecer o seunome.

• Pretende testar-se se o procedimento altera a tabela auxiliar de registo doconector quando e indicada uma tabela com o nome a NULL.


– uma com o nome da BD onde esta a tabela para cancelar o registo.

– uma a NULL.




56. O caso de teste e: cancelar o registo de uma tabela no conector fornecendo o nomevazio.

• Pretende testar-se se o procedimento altera a tabela auxiliar de registo doconector quando e indicada uma tabela com o nome vazio.







57. O caso de teste e: cancelar o registo de uma tabela no conector fornecendo a BD eo nome.

• Pretende testar-se se o procedimento utiliza o nome da BD e da tabela paracancelar o registo no conector.




– uma com o nome da tabela para registar.




Testes de caixa branca ao procedimento: unregisterTableInCDC

Os parametros de entrada sao os mesmos que foram indicados anteriormente nostestes ao procedimento registerTableInCDC.

58. O caso de teste e: cancelar o registo de uma tabela inexistente registada.

• Pretende verificar-se se o procedimento cancela o registo de tabelasinexistentes que tenham sido previamente registadas no conector.





• Pretende verificar-se se o procedimento cancela o registo de tabelasregistadas.




Testes de caixa branca ao procedimento: usp instalationScript

60. O caso de teste e: instalar o conector numa base de dados nova.

• Pretende verificar-se se o procedimento instala o conector numa base dedados nova.


– a criacao da tabela de configuracao do conector.

– a insercao de todos os valores pre-definidos na tabela de configuracao.


– a criacao da tabela auxiliar de registo de tabelas para o conector capturaralteracoes.


61. O caso de teste e: instalar o conector numa base de dados onde ja estava instaladopreviamente.

• Pretende verificar-se se o procedimento instala o conector numa base dedados onde este ja estava instalado.


– a remocao de todos os valores da tabela de configuracao.



62. O caso de teste e: instalar o conector numa base de dados em utilizacao mas sempre-instalacoes.

• Pretende verificar-se se o procedimento instala o conector numa base dedados em utilizacao mas onde nunca foi instalado.


– a criacao da tabela de configuracao do conector.


– a criacao da tabela auxiliar de registo de tabelas para o conector capturaralteracoes.


.1.3 Testes de integracao

• Casos de teste

Testes ao registo das tabelas no conector

1. O caso de teste e: registar as alteracoes de uma tabela nova.

– Pretende registar-se as alteracoes de uma nova tabela.

– Os resultados esperados sao:

∗ uma insercao na tabela auxiliar de registo do conector com a BD e onome da nova tabela.

∗ no SQL Server e criada uma tabela adicional para capturar asalteracoes ocorridas na tabela registada.


– Os resultados obtidos sao: os esperados.

2. O caso de teste e: registar uma tabela ja registada.

– Pretende registar-se uma tabela ja registada no conector.


∗ um reinıcio da captura das alteracoes nessa tabela.

– Os resultados obtidos sao:

∗ no SQL Server sao removidas todas as alteracoes capturadas e eatualizado o numero, nome e tipo das colunas.

∗ no MySQL ocorrem zero alteracoes pois a tabela ja registadacontinua registada.

3. O caso de teste e: registar uma tabela inexistente.

– Pretende registar-se uma tabela inexistente.


∗ a tabela inexistente nao e registada.


∗ a tabela inexistente e registada na tabela auxiliar de registo doconector.


– Pretende cancelar-se o registo de uma tabela ja registada.


∗ a remocao de uma linha na tabela auxiliar de registo do conector.

∗ no SQL Server a remocao da tabela adicional que captura asalteracoes.


5. O caso de teste e: cancelar o registo de uma tabela nao registada.

– Pretende cancelar-se o registo de uma tabela nao registada.


∗ zero alteracoes.


6. O caso de teste e: cancelar o registo de uma tabela inexistente registada.

– Pretende cancelar-se o registo de uma tabela inexistente registada.


∗ a remocao de uma linha na tabela auxiliar de registo do conector.



7. O caso de teste e: eliminar uma tabela registada.

– Eliminar uma tabela registada.


∗ no SQL Server a remocao da tabela adicional que captura asalteracoes.

∗ no MySQL a tabela continua registada.


8. O caso de teste e: adicionar uma coluna a uma tabela registada.

– Pretende adicionar-se uma coluna a uma tabela existente registada noconector.


∗ o conector regista as alteracoes na nova coluna.


∗ no SQL Server o conector so regista as alteracoes na nova colunaquando se chamar o procedimento usp SyncAllCDCTables.

∗ no MySQL o conector regista todas as alteracoes na nova colunaimediatamente apos a sua insercao.

9. O caso de teste e: alterar o tipo de uma coluna de uma tabela registada.

– Pretende alterar-se o tipo de uma coluna numa tabela existente registadano conector.


∗ o conector regista as alteracoes na nova coluna.


∗ no SQL Server o conector so regista as alteracoes na nova colunaquando se chamar o procedimento usp SyncAllCDCTables.

∗ no MySQL o conector regista todas as alteracoes na colunaimediatamente apos a sua alteracao.

10. O caso de teste e: remover uma coluna de uma tabela registada.

– Pretende remover-se uma coluna numa tabela existente registada noconector.


∗ o conector regista as alteracoes sem a coluna removida.


∗ no SQL Server o conector continua a incluir a coluna removida atese chamar o procedimento usp SyncAllCDCTables.


∗ no MySQL o conector regista todas as alteracoes sem a colunaimediatamente apos a sua remocao.

11. O caso de teste e: cancelar o registo de uma tabela.

– Pretende remover-se uma tabela registada no conector.


∗ o conector deixa de registar as alteracoes na tabela.


∗ no SQL Server o conector remove a tabela removida do seu registona captura de alteracoes seguinte.

∗ no MySQL o conector apresenta os resultados esperados.

Testes a captura de alteracoes nas tabelas registadas

12. O caso de teste e: inserir uma linha numa tabela.

– Pretende inserir-se uma linha numa tabela.


∗ a tabela fica com mais uma linha na BD.

∗ o conector regista a adicao de uma linha.

∗ quando passar o tempo do agendamento, a linha adicionada eincluıda no JSON com todas as alteracoes registadas.

∗ os valores introduzidos na tabela sao publicados no intermediarioKafka em formato JSON.


13. O caso de teste e: inserir varias linhas numa tabela.

– Pretendem inserir-se varias linhas numa tabela registada no conector.


∗ a tabela fica com mais linhas na BD.

∗ o conector regista a adicao de varias linhas.

∗ quando passar o tempo do agendamento, as linhas adicionadas saoincluıdas no JSON com todas as alteracoes registadas.



14. O caso de teste e: inserir varias linhas em varias tabelas.

– Pretendem inserir-se varias linhas em varias tabelas registadas noconector.



∗ as tabelas ficam com mais linhas na BD.

∗ o conector regista a adicao de varias linhas em varias tabelas.

∗ quando passar o tempo do agendamento, as linhas adicionadas saoincluıdas no JSON com todas as alteracoes registadas.



15. O caso de teste e: atualizar uma linha numa tabela.

– Pretende atualizar-se uma linha numa tabela registada no conector.


∗ uma linha da tabela e alterada mas fica com o mesmo numero delinhas na BD.

∗ o conector regista a alteracao de uma linha numa tabela.

∗ quando passar o tempo do agendamento, a linha alterada e incluıdano JSON com todas as alteracoes registadas.

∗ os valores alterados na tabela sao publicados no intermediario Kafkaem formato JSON.


16. O caso de teste e: atualizar varias linhas numa tabela.

– Pretendem atualizar-se varias linhas numa tabela registada no conector.


∗ a tabela fica atualizada mas com o mesmo numero de linhas na BD.

∗ o conector regista a alteracao de varias linhas.

∗ quando passar o tempo do agendamento, as linhas alteradas saoincluıdas no JSON com todas as alteracoes registadas.



17. O caso de teste e: atualizar varias linhas em varias tabelas.

– Pretendem atualizar-se varias linhas em varias tabelas registadas noconector.


∗ as tabelas ficam atualizadas mas com o mesmo numero de linhas naBD.


∗ o conector regista a alteracao de varias linhas em varias tabelas.

∗ quando passar o tempo do agendamento, as linhas alteradas saoincluıdas no JSON com todas as alteracoes registadas.



18. O caso de teste e: remover uma linha numa tabela.

– Pretende remover-se uma linha numa tabela.


∗ a tabela fica com menos uma linha na BD.

∗ o conector regista a remocao de uma linha.

∗ quando passar o tempo do agendamento, a linha removida e incluıdano JSON com todas as alteracoes registadas.

∗ os valores removidos na tabela sao publicados no intermediarioKafka em formato JSON.


19. O caso de teste e: remover varias linhas numa tabela.

– Pretendem remover-se varias linhas numa tabela registada no conector.


∗ a tabela fica com um menor numero de linhas na BD.

∗ o conector regista a remocao de varias linhas.

∗ quando passar o tempo do agendamento, as linhas removidas saoincluıdas no JSON com todas as alteracoes registadas.



20. O caso de teste e: remover varias linhas em varias tabelas.

– Pretendem remover-se varias linhas em varias tabelas registadas noconector.


∗ as tabelas ficam com um menor numero de linhas na BD.

∗ o conector regista a remocao de varias linhas em varias tabelas.




Figura 1: Tabela de producao com poucas colunas


∗ as tabelas ficam com um menor numero de linhas na BD.

∗ o conector regista a remocao de varias linhas em varias tabelas.



.2 Exemplos de tabelas de producao

.3 Diagrama Gantt


Figura 2: Tabela de producao com muitas colunas


Figura 3: Diagrama Gantt parte 1


Figura 4: Diagrama Gantt parte 2


Figura 5: Legenda do diagrama Gantt

Analise e Integrac¸´ ao de Infraestruturas para...

Documents

Transcript of Analise e Integrac¸´ ao de Infraestruturas para...