Análise do Protótipo

processa os dados e os avalia conforme as regras cadastradas. A cada problema        encontrado, a ferramenta o classifica conforme as Dimensões de Qualidade e armazena­a,        para que possa ser relatado ao fim da avaliação. O armazenamento das informações é feito        de forma que é possível resgatá­las para a apresentação no relatório, ou para geração de        gráficos na interface gerencial do protótipo. Portanto, ficam armazenadas na base de dados        do protótipo as informações referentes aos problemas encontrados para cada registro e os        dados contidos em cada registro que possui problema. Os registros que não possuem        problema   detectado   não   são   duplicados   para   a   base   do   protótipo. 

Por fim, o protótipo também possui uma funcionalidade para emissão dos relatórios        de problemas detectados. Os relatórios são apresentados não apenas em formato de        gŕaficos que mostram quais as tabelas, ou até colunas, possuem mais problemas, mas        também quais as Dimensões de Qualidade são mais afetadas. Além disso, permite a        exportação de relatório em formato de planilha contendo a descrição de cada um dos        problemas encontrados. Com a intenção de facilitar e estimular o uso da ferramenta, foi        proposta uma interface amigável para uso dos gestores, que exibe, em formato de gráficos,        os   relatórios   da   avaliação   da   Qualidade   dos   Dados.  

Esta seção está divida em duas subseções. A primeira apresenta os detalhes da        etapa   de   análise   do   protótipo.   E   a   segunda   apresenta   as   telas   desenvolvidas. 

5.1.1.

Análise   do   Protótipo 

Na sequência do andamento do trabalho, foi então iniciada a etapa de análise do        protótipo a ser implementado. O primeiro artefato gerado nessa análise foi o Diagrama de        Caso de Uso, apresentado na Figura 7, que representa os atores e as principais        funcionalidades   do   protótipo. 

Conforme apresentado no diagrama de caso de uso, o protótipo prevê a atuação de        dois atores. O primeiro ator, denominado “Database Administrator”, deve possuir um perfil        mais técnico e tem acesso às funcionalidades relacionadas ao cadastro dos Conjuntos de        Dados e das Regras de Validação que devem ser verificados, que são: “ Create new          DataSet” ,  ”Create new DataTable” , “ Create new DataColumn” , “ Create new Constraint to                     

DataColumn” . Já o segundo ator, denominado “ Business Analyst ”, possui um perfil para              consulta aos Relatórios de Problemas de Qualidade, cuja funcionalidade é nomeada “ View        evaluation Report ”, e para solicitar ao sistema que realize uma nova avaliação, nomeada        “ Execute   new   evaluation ”.     Figura   7   ­   Diagrama   de   Caso   de   Uso    Fonte:   elaborada   pelo   autor   

Além do Diagrama de Caso de Uso, outro artefato gerado na análise foi o Diagrama        de Classes apresentado na Figura 8, que define a estrutura das classes da aplicação e,        consequentemente, do banco de dados onde serão armazenados todos os dados referentes        à definição dos conjuntos de dados, à definição das Regras de Validação e à detecção dos        Problemas de Qualidade. O diagrama de classes se apresenta em três pacotes. Cada um        deles  destaca  uma  das  partes  do  protótipo.  No  primeiros deles, nomeado      “ Constrainsts_Dimensions ”, estão as classes que contêm as informações que já vêm pré        definidas no protótipo, que são os tipos de dados, as Dimensões de Qualidade dos Dados, e        os conjuntos de Regras de Validação que podem ser verificados pelo protótipo. As Regras        de Validação já são associadas aos tipos de dados e às Dimensões de Qualidade. No        segundo pacote, nomeado “ DataSet_Constraint ”, estão as classes que serão utilizadas para        armazenar quais dados serão avaliados, e quais Regras de Validação serão aplicadas a        cada atributo. No terceiro pacote, nomeado “ DataSet_Evaluation ”, estão as classes que       

Figura   8   ­   Diagrama   de   Classes 

Após concluída a etapa inicial de análise do protótipo, outra etapa importante para        iniciar o desenvolvimento foi a escolha da linguagem de programação. Para tomar essa        decisão foram verificados, basicamente, dois fatores: a existência de um framework de        desenvolvimento ágil para a  Web , e a existência de ferramentas que auxiliam na validação        de   dados.  

Atualmente, praticamente todas as linguagens de programação mais conhecidas já        possuem bons frameworks de desenvolvimento ágil para a  Web . Portanto, o passo inicial foi        pesquisar   por   ferramentas   que   pudessem   auxiliar   no   processo   de   Validação   dos   Dados.   

Inicialmente, algumas bibliotecas de validação de dados foram encontradas, como        formValidation  ,  Cerberus  , e outras. A maior parte das ferramentas encontradas2  3        destinam­se a validação de dados de formulários  Web . No entanto, apesar de ser uma        aplicação  Web, o protótipo deve detectar problemas em dados que já estão armazenados.        Portanto, dentre todas as ferramentas analisadas, destaca­se a biblioteca  Cerberus devido à        sua aplicação dentre os conjuntos de Regras de Validação previamente definidos, a        possibilidade de utilizá­la fora do ambiente de um navegador e a sua capacidade de ser        estendida   caso   necessário.  

Considerando os benefícios do uso da biblioteca  Cerberus , que foi escrita em  Python        , e a existência do  framework Django , que possibilita um desenvolvimento  W eb rápido e foi              4

escrito na mesma linguagem de programação; foi definido que o protótipo seria desenvolvido        com   a   linguagem   de   programação    Python,    fazendo   uso   do    framework   Django .  

Além disso, como um dos requisitos era que o sistema possuísse uma interface        amigável e intuitiva, foi definido que seria utilizado um framework para desenvolvimento de        telas responsivas. Na escolha deste framework ficou definido o uso do  Bootstrap  , bem      5    como o uso de um template popular e gratuito para construção das telas. Dentre as opções        de templates gratuitos para utilizar no protótipo foi definido o uso do  AdminLTE  , que possui      6      uma   grande   quantidade   de   componentes   e   plugins   pré­definidos.    2   _{Encontrada   em   http://formvalidation.io/}  3   _{Encontrada   em   http://docs.python­cerberus.org/}  4   _{Encontrada   em   https://www.python.org/}  5   _{Encontrado   em   http://getbootstrap.com/} 

5.1.2.

Desenvolvimento   do   Protótipo 

O protótipo foi batizado com o nome  DataQualityControl  . A escolha do nome teve      7        origem no objetivo do uso da ferramenta, que é o de detectar Problemas de Qualidade em        conjuntos   de   dados   e,   com   isso,   auxiliar   no   controle   da   Qualidade   dos   Dados.  

A Figura 9 apresenta a tela inicial do protótipo, que é a tela de listagem dos        Conjuntos de Dados que estão cadastrados para serem avaliados. A partir desta tela é        possível visualizar os detalhes de cada conjunto de dados já cadastrados, cadastrar um        novo conjunto de dados, ou visualizar os resultados das últimas avaliações realizadas para        cada conjunto de dados. A listagem dos Conjuntos de Dados apresenta o nome e a        descrição do Conjunto de Dados, assim como a quantidade de tabelas, colunas e Regras de        Validação   cadastradas   para   cada   um   deles.     Figura   9   ­   Tela   Inicial:      Listagem   de   Conjuntos   de   Dados    Fonte:   elaborada   pelo   autor    7   _{O   código   fonte   do   protótipo   está   disponível   no   repositório   https://github.com/arturcalves/dqc}