Crystal de Menezes Santos
CRYSTAL: UMA LINGUAGEM DE MODELAGEM SIMPLIFICADA
PARA APOIAR A ESPECIFICAÇÃO DE PROGRAMAS
PROCEDURAIS EM BANCO DE DADOS RELACIONAIS
Universidade Federal de Pernambuco posgraduacao@cin.ufpe.br www.cin.ufpe.br/~posgraduacao
RECIFE 2017
Crystal de Menezes Santos
CRYSTAL: UMA LINGUAGEM DE MODELAGEM SIMPLIFICADA
PARA APOIAR A ESPECIFICAÇÃO DE PROGRAMAS
PROCEDURAIS EM BANCO DE DADOS RELACIONAIS
Trabalho apresentado ao Programa de Pós-graduação em Ciência da Computação do Centro de Informática da Univer-sidade Federal de Pernambuco como requisito parcial para obtenção do grau de Mestre em Ciência da Computação.
Orientador: Robson do Nascimento Fidalgo
RECIFE 2017
Catalogação na fonte
Bibliotecária Monick Raquel Silvestre da S. Portes, CRB4-1217
S237c Santos, Crystal de Menezes
Crystal: uma linguagem de modelagem simplificada para apoiar a especificação de programas procedurais em banco de dados relacionais / Crystal de Menezes Santos . – 2017.
107 f.: il., fig.
Orientador: Robson do Nascimento Fidalgo.
Dissertação (Mestrado) – Universidade Federal de Pernambuco. CIn, Ciência da Computação, Recife, 2017.
Inclui referências.
1. Banco de dados. 2. Linguagem visual de programação. I. Fidalgo, Robson do Nascimento (orientador). II. Título.
025.04 CDD (23. ed.) UFPE- MEI 2017-92
Crystal de Menezes Santos
Crystal: Uma Linguagem de Modelagem Simplificada para Apoiar a
Especificação de Programas Procedurais em Banco de Dados
Relacionais
Dissertação de Mestrado apresentada ao Programa de Pós-Graduação em Ciência da Computação da Universidade Federal de Pernambuco, como requisito parcial para a obtenção do título de Mestre em Ciência da Computação
Aprovado em: 17/02/2017.
BANCA EXAMINADORA
______________________________________________ Prof. Dr. Fernando da Fonseca de Souza
Centro de Informática / UFPE
____________________________________________ Profa. Dra. Liliana Maria Passerino
Departamento de Estudos Especializados/UFRGS ___________________________________________
Prof. Dr. Robson do Nascimento Fidalgo Centro de Informática / UFPE
Dedico essa dissertação aos meus pais, que sempre me motivam a continuar crescendo.
Agradecimentos
Primeiramente, agradeço a Deus por permitir a realização deste mestrado e por tudo em minha vida. Agradeço a meus pais, Renato e Maria Luiza, pela inspiração em continuar meus estudos e superar todos os obstáculos que aparecem no caminho. Agradeço a meus irmãos e minha família por me impulsionarem a ser uma pessoa melhor todos os dias. Também agradeço a Victor Antonino pela sua paciência e dedicação comigo ao longo do desenvolvimento deste trabalho. Sem seu suporte, este trabalho possivelmente não teria sido concluído com tanta determinação.
Por fim, gostaria de agradecer ao meu orientador Robson Fidalgo por ter aceitado me direcionar nesta pesquisa e por sua mais absoluta paciência em todos os momentos difíceis ao longo dessa jornada.
The limits of my language are the limits of my world. — LUDWIG WITTGENSTEIN
Resumo
No contexto deste trabalho, uma linguagem de modelagem é qualquer linguagem artificial que, a partir de um conjunto consistente de construtores e de regras de associação entre estes, pode ser usada para diagramar um domínio e, consequentemente, gerar código interpretável ou executável. O uso de linguagem de modelagem para diagramar programas procedurais em Banco de Dados Relacionais ainda é um tema que tem limitações, principalmente: metamodelos pouco expres-sivos (ou inexistentes) e notação gráfica sobrecarregada e pouco abrangente. Visando superar estas limitações, esta dissertação propõe Crystal, uma linguagem de modelagem simplificada para apoiar a especificação de programas procedurais para Banco de Dados Relacionais. Crystal é fortemente baseada em Model Driven Development (MDD) – um paradigma da Engenharia de So f tware que gera código interpretável/executável a partir de modelos. Isto é, em MDD, mode-los são mais do que artefatos de documentação, pois estes correspondem a objetos executáveis. Visando mostrar a viabilidade da linguagem proposta, a ferramenta CrystalCASE é desenvolvida como prova de conceito. Além disso, de modo a apresentar evidências que o trabalho proposto avança o estado da arte, são especificados cenários de testes que exploram os principais constru-tores de Procedural Language/Structured Query Language (PLSQL) e, a partir desses cenários, o trabalho proposto é comparado com os principais trabalhos relacionados. Como resultado das análises comparativas, pode-se constatar que o trabalho proposto tem as seguintes vantagens: metamodelo mais expressivo e notação gráfica mais simplificada e representativa.
Palavras-chave: Desenvolvimento Dirigido por Modelo. Linguagem de Modelagem de Domínio Específico. Linguagem Visual de Programação. Ferramenta CASE. Transformação de Modelo. Desenvolvimento Dirigido a Modelo.
Abstract
Within the context of this dissertation, a modeling language is any artificial language that, from a set of consistent constructors and rules of association between them, can be used to diagram a domain and, consequently, generate interpretable or executable code. The use of modeling language to diagram procedural programs in relational database is still a limited subject within boundaries, mostly: unexpressive (or inexisting) metamodels and meticulous and overloaded graphic notation. Aiming at overcoming limits, this dissertation proposes Crystal, a modeling simplified language to support procedural program specification for relational databases. Crystal is strongly based in Model Driven Development (MDD) - Software Engineering paradigm that generates interpretable/executable code from existing models. That is, in MDD, models are more than documentation assets, because such models correspond to executable objects. In order to show the feasibility of the proposed language, the CrystalCASE tool is developed as proof of concept. Beyond that, in order to present evidence that the proposed model advances the state of the art, test scenarios are specified exploring the main Procedural Language/Structured Query Language (PLSQL) constructors and, from these scenarios, the proposed model is compared with most relevant related work. As a result of the comparative analysis, it can be seen that the proposed model presents the following advantages: more expressive metamodel and more simplified and representational graphic notation.
Keywords: Model Driven Development. Domain-Specific Modeling Language. Visual Pro-gramming Language. CASE tool. Model transformation.
Lista de Figuras
2.1 Exemplo de um Modelo de Características para o domínio Carro . . . 28
2.2 Representações das funcionalidades da metodologia FODA . . . 28
2.3 Análise de Domínio . . . 29
2.4 Classificação topológica de Linguagem Visual de Programação (LVP) . . . 30
2.5 Hierarquia das abordagens MDE, MDA e MDD . . . 31
2.6 Padrão de metamodelo em MDD . . . 32
2.7 Processo de desenvolvimento de Linguagem de Modelagem Específica de Domí-nio (DSML) . . . 33
3.1 Exemplos de tela do trabalho proposto em Reis (2011). . . 39
3.2 Exemplo de uma rotina de entrada para a ferramenta SQLFlow . . . 41
3.3 Diagramas gerados pela ferramenta SQLFlow. . . 42
3.4 Exemplo de utilização da ferramenta proposta por Habringer; Moser; Pitchler (2014) . . . 44
3.5 Exemplo de fluxograma gerado pelo so f tware Visustin. . . 46
3.6 Exemplo de fluxograma gerado pelo so f tware Code Visual to Flowchart. . . . 48
4.1 Hierarquia de Características dos construtores primários da linguagem Crystal . 53 4.2 Hierarquia das características denominadas de Parte Declarativa e Retorno . . . 54
4.3 Hierarquia das características que representam tipos de dados na linguagem Crystal . . . 54
4.4 Hierarquia da característica chamada de Parâmetros . . . 55
4.5 Hierarquia das características Parâmetros IN, OUT e IN OUT da linguagem Crystal . . . 56
4.6 Hierarquia da característica chamada Parte Executável . . . 56
4.7 Hierarquia dos componentes que compõem a característica chamada Parte Exe-cutável . . . 57
4.8 Hierarquia dos construtores que compõem o componente chamado Estruturas Condicionais da linguagem Crystal . . . 58
4.9 Hierarquia dos construtores que compõem o componente chamado Estruturas de Repetição da linguagem Crystal . . . 58
4.10 Ícones dos construtores que representam as rotinas na linguagem Crystal . . . 59
4.11 Representação das rotinas da linguagem PL/SQL na linguagem Crystal . . . . 60
4.12 Ícones e representações dos componentes das Estruturas de Decisão . . . 60
4.13 Ícones e representações dos componentes das Estruturas de Repetição . . . 61 4.14 Ícones dos componentes que formam a Parte Executável da linguagem Crystal 62
4.15 Representação dos componentes formam a Parte Executável da linguagem Crystal 62
4.16 Ícones e representações dos Tipos de Dados da linguagem Crystal . . . 63
4.17 Ligações e representações dos conectores da linguagem Crystal . . . 64
4.18 Metamodelo das enumerações da linguagem Crystal . . . 64
4.19 Detalhamento da metaclasse principal da linguagem Crystal . . . 65
4.20 Detalhamento da metaclasse Subprograms da linguagem Crystal . . . 65
4.21 Detalhamento da metaclasse Data Abstractions da linguagem Crystal . . . 66
4.22 Detalhamento da metaclasse Statements da linguagem Crystal . . . 67
4.23 Detalhamento das metaclasses CallBlocks e AdditionalOperations da lingua-gem Crystal . . . 67
4.24 Detalhamento das metaclasses CursorOperations e SQLOperations da lingua-gem Crystal . . . 68
4.25 Detalhamento da metaclasse Conditional Structures da linguagem Crystal . . . 69
4.26 Detalhamento da metaclasse Iterations Structures da linguagem Crystal . . . . 69
4.27 Detalhamento da metaclasse Links da linguagem Crystal . . . 70
4.28 Metamodelo da linguagem Crystal . . . 71
4.29 Representação de um erro sintático na linguagem Crystal . . . 72
5.1 Exemplo de sintaxe da linguagem EVL . . . 76
5.2 Exemplo de sintaxe da linguagem EGL . . . 76
5.3 Ferramenta CrystalCASE . . . 77
5.4 Apresentação de erros na ferramenta CrystalCASE . . . 77
5.5 Utilização do Construtor I f . . . 78
5.6 Utilização do Construtor Case . . . 79
5.7 Utilização do Construtor Options . . . 79
5.8 Utilização dos construtores de repetição . . . 80
5.9 Utilização dos construtores que representam Chamadas a Rotinas . . . 80
5.10 Utilização dos construtores que representam comandos SQL . . . 81
5.11 Utilização dos construtores que representam Abstrações de Dados . . . 82
5.12 Utilização dos construtores para Manipulação de Cursor . . . 82
5.13 Utilização dos construtores Exception e Expression . . . 83
5.14 Modelo ER utilizado nos exemplos . . . 83
5.15 Bloco Anônimo que percorre uma lista de Funcionários e atualiza os salários -Diagrama . . . 85
5.16 Código gerado a partir do diagrama da Figura 5.15 . . . 86
5.17 Procedimento que insere novos Departamentos e imprime na tela o nome dos Departamentos cadastrados . . . 86
5.19 Função que realiza operações de CRUD no Banco de Dados e retorna a quanti-dade de Funcionarios . . . 88 5.20 Código gerado a partir do diagrama da Figura 5.19 . . . 89 5.21 Reprodução do exemplo da Figura 5.17 na ferramenta de Reis (2011) . . . 90 5.22 Reapresentação dos exemplos da ferramenta (TARTIR; ISSA,2005)
apresenta-dos no Capítulo 3 . . . 91 5.23 Reprodução do exemplo da ferramenta SQLFlow na ferramenta CrystalCASE
-Código . . . 91 5.24 Reprodução do exemplo da ferramenta SQLFlow na ferramenta CrystalCASE
-Diagrama . . . 92 5.25 Reapresentação dos exemplos da ferramenta proposta por Habringer; Moser;
Pitchler (2014) . . . 93 5.26 Reprodução do exemplo da ferramenta proposta por Habringer; Moser; Pitchler
(2014) na ferramenta CrystalCASE - Código . . . 93 5.27 Reprodução do exemplo da ferramenta proposta por (HABRINGER; MOSER;
PICHLER,2014) na ferramenta CrystalCASE - Diagrama . . . 94 5.28 Diagramas na ferramenta Visustin referentes ao exemplo apresentado na Figura
5.15 . . . 94 5.29 Diagramas na ferramenta Visustin referentes ao exemplo apresentado na Figura
5.17 . . . 95 5.30 Diagramas na ferramenta Visustin referentes ao exemplo apresentado na Figura
5.19 . . . 96 5.31 Diagramas na ferramenta Code Visual to Flowchart referentes ao exemplo
apresentado na Figura 5.15 . . . 97 5.32 Diagramas na ferramenta Code Visual to Flowchart referentes ao exemplo
apresentado na Figura 5.17 . . . 98 5.33 Diagramas na ferramenta Code Visual to Flowchart referentes ao exemplo
12 12 12
Lista de Códigos
2.1 Estrutura básica de um Bloco Anônimo na linguagem PL/SQL . . . 22
2.2 Estrutura básica de uma Função na linguagem PL/SQL . . . 22
2.3 Estrutura básica de um Procedimento na linguagem PL/SQL . . . 22
2.4 Estrutura básica da seção Exceção na linguagem PL/SQL . . . 23
2.5 Estrutura básica da instrução IF na linguagem PL/SQL . . . 23
2.6 Estrutura básica da instrução Case na linguagem PL/SQL . . . 24
2.7 Estrutura básica da instrução While na linguagem PL/SQL . . . 24
2.8 Estrutura básica da instrução Loop na linguagem PL/SQL . . . 24
2.9 Estrutura básica da instrução For na linguagem PL/SQL . . . 24
2.10 Estrutura básica de um Cursor na linguagem PL/SQL . . . 25
2.11 Estrutura básica do tipo de dados Records na linguagem PL/SQL . . . 25
2.12 Estrutura básica do tipo de dados Collections na linguagem PL/SQL . . . 25
2.13 Estrutura básica da instrução Insert na linguagem PL/SQL . . . 26
2.14 Estrutura básica da instrução Update na linguagem PL/SQL . . . 26
2.15 Estrutura básica da instrução Delete na linguagem PL/SQL . . . 27
13 13 13
Lista de Quadros
3.1 Avaliação do trabalho proposto em (REIS,2011). . . 40
3.2 Avaliação do trabalho proposto em Tartir; Issa (2005). . . 43
3.3 Avaliação do trabalho proposto em Habringer; Moser; Pitchler (2014). . . 45
3.4 Avaliação do so f tware Visustin. . . 47
3.5 Avaliação do so f tware Code Visual to Flowchart. . . 49
3.6 Avaliação consolidada dos trabalhos e ferramentas analisados. . . 51
5.1 Indicação dos construtores que compõem cada exemplo . . . 84
5.2 Comparação da ferramenta CrystalCASE com os trabalhos relacionados apre-sentados no Capítulo 3 . . . 100
Lista de Acrônimos
CASE Computer Aided So f tware Engineering . . . 17
CRUD Create, Read, U pdate, Delete . . . 87
DSML Linguagem de Modelagem Específica de Domínio . . . 17
DDL Data Definition Language. . . .56
DML Data Manipulation Language . . . 56
EMF Eclipse Modeling Framework . . . 75
EVL Epsilon Validation Language . . . 75
EGL Epsilon Generation Language . . . 75
EMF Essential Meta Object Facility . . . 75
FODA Feature Oriented Domain Analysis . . . 17
GMF Graphical Modeling Framework . . . 75
GEF Graphical Editing Framework . . . 75
GMP Eclipse Graphical Modeling Project . . . 75
LVP Linguagem Visual de Programação. . . .17
MDD Model Driven Development . . . .17
Modelo ER Modelo Entidade-Relacionamento . . . 84
OCL Object Constraint Language . . . 75
PL/SQL Procedural Language Structured Query Language . . . 18
SGBD Sistema de Gerenciamento de Banco de Dados . . . 18
Sumário
1 Introdução 17 1.1 Contextualização 17 1.2 Problema e Motivação 18 1.3 Objetivo 19 1.4 Metodologia de Pesquisa 19 1.5 Estrutura da Dissertação 20 2 Fundamentação Teórica 212.1 Programação em Banco de Dados 21
2.2 Análise de Domínio 27
2.3 Linguagem Visual de Programação 29
2.4 Desenvolvimento de Software Dirigido por Modelos 31
2.5 Metodologia de Pesquisa para a Linguagem Crystal 34
2.6 Considerações Finais 34
3 Revisão da Literatura 36
3.1 Características para Avaliação 36
3.2 Trabalhos Acadêmicos 38 3.2.1 Reis 38 3.2.2 Tartir e Issa 40 3.2.3 Habringer e Pichler 42 3.3 Ferramentas 45 3.3.1 Visustin 46
3.3.2 Code Visual to Flowchart 47
3.4 Análise Consolidada 50
4 Uma Linguagem Visual de Programação para Banco de Dados 52 52
4.1 Visão Geral 52 4.2 Captura de Requisitos 53 4.3 Sintaxe Concreta 59 4.4 Sintaxe Abstrata 64 4.5 Semântica Estática 70 4.6 Considerações Finais 74 5 Ferramenta CrystalCASE 75
5.1 Implementação da Ferramenta CrystalCASE 75
5.2 Utilização da Ferramenta CrystalCASE 76
5.2.1 Utilização dos Construtores 78
5.3 Exemplos de uso 83
5.4 Comparação com os Trabalhos Relacionados 89
5.4.1 Reis 90
5.4.2 Tartir e Issa 90
5.4.4 Visustin 95
5.4.5 Code Visual to Flowchart 97
5.4.6 Análise Consolidada 99 5.5 Considerações Finais 101 6 Conclusão 102 6.1 Considerações Finais 102 6.2 Contribuições 103 6.3 Limitações 103 6.4 Trabalhos Futuros 104 Referências 105
17 17 17
1
Introdução
Este capítulo contextualiza e apresenta o problema de pesquisa que deu origem e motivou o desenvolvimento deste trabalho, os objetivos a serem alcançados, a metodologia de pesquisa utilizada para atingir estes objetivos e a estrutura dos demais capítulos desta dissertação.
1.1 Contextualização
No paradigma de Desenvolvimento Dirigido a Modelo, do inglês Model Driven Development (MDD), modelos são considerados como objetos executáveis e não mais meros artefatos de documentação. Isto é, uma vez que um modelo é criado seguindo regras de boa formação de sua linguagem de modelagem, este pode ser transformado automaticamente em outro mo-delo (i.e., transformação momo-delo-momo-delo ou M2M) ou em código executável/interpretável (i.e., transformação modelo-texto ou M2T)KELLY; TOLVANEN 2008. Uma das formas de seguir o paradigma MDD é com o uso de uma Linguagem de Modelagem Específica de Domínio (DSML) (DEURSEN; KLINT; VISSER,2000). Uma DSML é desenvolvida para oferecer, com o uso de notações e abstrações, uma maior expressividade a um domínio de um problema (DEURSEN; KLINT; VISSER,2000).
Existem diversos métodos para representar formalmente a análise do domínio de um pro-blema como, por exemplo, DARE ((FRAKES; PRIETO-;DIAZ; FOX,1998)), DSSA ((TRACZ,
1995)), FAST ((WEISS; LAI,1999)), ODE ((FALBO; GUIZZARDI; DUARTE,2002)) e ODM ((SIMOS,1995)). O método mais utilizado é o Feature Oriented Domain Analysis (FODA) ((KANG et al.,1990)). Esta técnica consiste em criar um modelo de características constituído pelas características ou propriedades que são relevantes para o sistema.
As DSML são implementadas por ferramentas Computer Aided So f tware Engineering (CASE), que podem ajudar a detectar erros com antecedência, auxiliando na completude e consistência da modelagem criada e pode guiar o usuário por meio de um padrão de design (CASE, 1985). Para aumentar a expressividade de uma DSML, pode-se fazer uso de uma Linguagem Visual de Programação (LVP), a qual permite a codificação com o uso de elementos gráficos, ao invés de especificá-los de forma textual (VERGARA,1991). Desta forma, os ícones
1.2. PROBLEMA E MOTIVAÇÃO 18 formam o contexto primário da linguagem em uma ordem sistemática e podem ser utilizados para representar entradas, atividades, conexões e/ou saídas do sistema (CHANG; ICHIKAWA; LIGOMENIDES,1986).
Existe um processo na Engenharia de So f tware chamado Engenharia Direta (do inglês, Forward Engineering) que inicia-se em um modelo e termina em um código executável ou in-terpretável, da mesma forma que a transformação M2T do paradigma MDD. O processo inverso é conhecido como Engenharia Reversa (do inglês, Reverse Engineering ou Back Engineering), e tem como objetivo construir um modelo a partir de código executável ou interpretável. As transformações necessárias para estes processos devem envolver todas as decisões de projeto possíveis para o domínio, como, por exemplo: generalização/especialização, otimização, de-composição, representação, escolha de algoritmos, compartilhamento de recursos, entre outros (BAXTER; MEHLICH,1997).
De acordo com o ranking apresentado pela empresa Austrian IT Consulting1, atual-mente o Oracle é o Sistema de Gerenciamento de Banco de Dados (SGBD) mais popular. Este SGBD utiliza a linguagem Procedural Language Structured Query Language (PL/SQL) ( MO-ORE,2009), uma extensão da linguagem Structured Query Language (SQL) (MOORE,2009). A linguagem PL/SQL adiciona instruções que não são nativas da linguagem SQL (por exemplo, estruturas de decisão e de repetição) combinando, assim, o poder de manipulação dos dados de SQL com o poder de processamento de dados das linguagens procedurais.
1.2 Problema e Motivação
Existem diversas linguagens para criação de programas procedurais para Banco de Dados Relacionais. Apesar de possuírem similaridades, estas linguagens diferem em sintaxe, tipo de dados e arquitetura e os projetistas devem estar cientes destas diferenças. Por exemplo, a linguagem MySQL possui apenas dois tipos de dados para representação de caracteres chamados ’CHAR’ e ’VARCHAR’, enquanto que a linguagem PL/SQL possui quatro tipos, chamados ’CHAR’, ’VARCHAR2’, ’NCHAR’ e ’NVARCHAR2’. Para compreender estas diferenças, é necessário tempo de estudo e prática para que os projetistas de Banco de Dados assimilem este aprendizado.
Considerando este contexto, encontra-se na literatura dois problemas: 1) quase não é pos-sível encontrar linguagens de modelagem que apoiem a especificação de programas procedurais para Banco de Dados Relacionais para uma linguagem específica; e 2) são poucas as ferramentas que realizam a Engenharia Direta para este tipo de domínio. A expressividade e um maior nível de abstração que uma DSML oferece em comparação a linguagens puramente textuais ainda é pouco explorado para este cenário.
Dados os problemas apresentados e considerando-se que o uso da metodologia MDD e Transformações de Modelo ainda são temas de pesquisa pouco explorados no contexto de Banco
1.3. OBJETIVO 19 de Dados, a motivação para o desenvolvimento deste trabalho é: se desconhece a existência de outro trabalho que, à luz de MDD e considerando o domínio para a construção de rotinas de Banco de Dados Relacionais, defina uma DSML com uma notação simplificada para auxiliar projetistas a construir rotinas por meio de diagramas, de forma a ser possível abstrair alguns detalhes técnicos de linguagens de programação textuais.
1.3 Objetivo
Considerando a diferença de sintaxe entre os diversos SGBD atuais, o objetivo geral deste trabalho é garantir que os projetistas possam abstrair detalhes técnicos de sintaxe, direcionando o seu conhecimento para a parte lógica das rotinas de banco de dados que estão sendo desenvolvidas. Este objetivo é alcançado ao criar uma linguagem de modelagem com uma notação simplificada, que realiza a transformação de modelo para código. A partir do objetivo geral, podem-se descrever os seguintes objetivos específicos:
1. Identificar o domínio da linguagem PL/SQL a ser utilizado neste trabalho;
2. Especificar uma notação para a linguagem visual que dê sentido ao que o usuário está criando, de forma a facilitar o entendimento do código que será gerado e resulte em uma notação simples;
3. Especificar quais elementos são necessários modelar para ser possível realizar a construção do código automático; e
4. Implementar e avaliar as propostas apresentadas neste trabalho a partir de uma ferramenta CASE, que realiza Engenharia Direta para os modelos criados.
1.4 Metodologia de Pesquisa
Na Engenharia de Software, os métodos de pesquisa podem ser classificados em quatro tipos: científico, da engenharia, empírico e analítico (TRAVASSOS,2002). O chamado método da engenharia define-se por ser uma abordagem orientada à melhoria evolutiva que assume a existência de algum modelo do processo ou produto de software e modifica este modelo com propósito de melhorar os objetos do estudo. Este trabalho foi desenvolvido baseando no método da engenharia, pois inicia-se com a observação das soluções existentes, e sugere uma solução mais adequada, a qual é desenvolvida e analisada.
De acordo com o método da engenharia, a pesquisa é composta por três fases:
1. Revisão da Literatura: etapa na qual é realizado um estudo sobre os conceitos, características, trabalhos existentes na literatura, problemas e possíveis soluções em linguagem para diagramação de rotinas de banco de dados;
1.5. ESTRUTURA DA DISSERTAÇÃO 20 2. Processo de Design: planejamento e desenvolvimento de uma linguagem que realize a transformação de diagramas para código, com base no processo de transformação MDD; e
3. Avaliação: desenvolvimento de exemplos para ser possível realizar comparação do trabalho desenvolvido com os trabalhos existentes na literatura, a fim de apresentar uma visão crítica sobre os critérios considerados fundamentais para este tipo de linguagem e ferramenta.
1.5 Estrutura da Dissertação
Para apresentar os conceitos e tecnologias relacionadas e utilizadas neste trabalho, bem como atingir seus objetivos especificados, os demais Capítulos desta dissertação estão organizados conforme descrito a seguir. O Capítulo 2 apresenta os conceitos básicos e as tecnologias relacionadas a este trabalho, essenciais para seu entendimento. O Capítulo 3 apresenta uma avaliação dos principais trabalhos relacionados existentes no estado da arte, ressaltando suas vantagens e desvantagens. O Capítulo 4 apresenta detalhes da metodologia utilizada no desenvolvimento deste trabalho para alcançar os objetivos especificados. O Capítulo 5 apresenta a ferramenta desenvolvida neste trabalho, assim como uma avaliação comparativa desta ferramenta com os trabalhos apresentados no Capítulo 3. E, por fim, o Capítulo 6 apresenta as conclusões deste trabalho, a principal contribuição para a literatura e indicações de possíveis trabalhos futuros.
21 21 21
2
Fundamentação Teórica
Neste Capítulo, são apresentados os conceitos necessários para um melhor entendimento da presente dissertação. Tais conceitos estão divididos nos tópicos: Programação em Banco de Dados, a metodologia de análise de domínio denominada FODA, definição de linguagens visuais de programação ou LVP e Desenvolvimento de So f tware Dirigido por Modelos.
2.1 Programação em Banco de Dados
Oracle é um SGBD que possui facilidade de integração com inúmeras linguagens de programação. Para o desenvolvimento de programas, este SGBD utiliza a linguagem PL/SQL, que é uma extensão da linguagem declarativa SQL. Com PL/SQL, pode-se fazer uso de funcio-nalidades que não estão presentes na linguagem SQL, como, por exemplo, estruturas de decisão e estruturas de repetição, tornando a linguagem de desenvolvimento mais expressiva (MURRAY,
2013). Esta seção apresenta as construções básicas da linguagem PL/SQL que são utilizadas e referenciadas ao longo deste trabalho.
Subprogramas (ou sub-rotinas) são blocos PL/SQL que realizam uma tarefa específica e possuem a opção de serem chamados com um conjunto de parâmetros de entrada e/ou saída. A linguagem PL/SQL possui três tipos de subprogramas: Blocos Anônimos, Procedimentos e Funções. Os Blocos Anônimos são utilizados para executar um conjunto de comandos PL/SQL na ordem declarada, porém, não são armazenados de forma definitiva no banco de dados (MURRAY,2013). Um Bloco Anônimo é formado por três partes: uma seção de declaração de variáveis, uma seção executável e uma seção para tratamento de erros. Sua estrutura básica é apresentada no Código 2.1. Em contrapartida, as Funções e os Procedimentos são compilados e armazenados de forma definitiva no banco de dados, estando disponíveis para serem executados posteriomente. Normalmente, Procedimentos são utilizados para realizar uma ação específica de forma segura com uma única transação enquanto que Funções são utilizadas para calcular valores (MURRAY,2013). Funções devem retornar valores de forma explícita, enquanto que Procedimentos podem retornar valores por meio dos Parâmetros OUT ou IN OUT.
2.1. PROGRAMAÇÃO EM BANCO DE DADOS 22 também possuem em sua formação uma seção para declaração de parâmetros. Como em Funções é possível retornar valores, esta sub-rotina possui ainda uma seção para a declaração do retorno. A estrutura básica de Funções e Procedimentos está apresentada, respectivamente, nos Códigos 2.2 e 2.3. Os três tipos de sub-rotinas apresentam uma seção opcional para tratamento de exceções que são erros em tempo de execução que podem ser pré-definidos, disparados implicitamente pelo sistema, ou definidos pelo usuário, declarados explicitamente no código (MURRAY,2013). Um bloco de instruções pode ser executado para realizar o tratamento de cada exceção identificada, como pode ser visto na estrutura apresentada no Código 2.4.
Código 2.1: Estrutura básica de um Bloco Anônimo na linguagem PL/SQL
[DECLARE] BEGIN -- statements [EXCEPTION] END; /
Código 2.2: Estrutura básica de uma Função na linguagem PL/SQL
CREATE [OR REPLACE] FUNCTION function_name
[ (parameter_name [IN | OUT | IN OUT] type [, ...]) ]
RETURN return_datatype IS | AS [declaration_section] BEGIN -- executable_section [EXCEPTION] END [function_name];
Código 2.3: Estrutura básica de um Procedimento na linguagem PL/SQL
CREATE [OR REPLACE] PROCEDURE procedure_name
[ (parameter_name [IN | OUT | IN OUT] type [, ...]) ]
IS [declaration_section] BEGIN -- executable_section [EXCEPTION] END [procedure_name]; /
2.1. PROGRAMAÇÃO EM BANCO DE DADOS 23 Código 2.4: Estrutura básica da seção Exceção na linguagem PL/SQL
DECLARE
-- declarations_section
BEGIN
-- executable_section
EXCEPTION
-- exception handling goes here
WHEN exception1 THEN
exception1-handling-statements
WHEN exception2 THEN
exception2-handling-statements
WHEN exception3 THEN
exception3-handling-statements ...
WHEN others THEN
exception3-handling-statements
END;
/
Código 2.5: Estrutura básica da instrução IF na linguagem PL/SQL
IF condition1 THEN
-- statements to execute when condition1 is TRUE
ELSIF condition2 THEN
-- statements to execute when condition2 is TRUE
ELSE
-- statements to execute when conditions above are FALSE.
END IF;
/
A linguagem PL/SQL possui duas estruturas condicionais: IF e CASE. A primeira estrutura condicional, o comando IF, permite que uma sequência de outros comandos sejam executados/saltados dependendo de uma condição. Existem três formas de se utilizar este comando: IF T HEN, IF T HEN ELSE e IF T HEN ELSIF. A segunda estrutura condicional é o comando CASE, que deve ser utilizado quando existem diferentes ações para serem executadas dependendo do valor de uma expressão (MURRAY,2013). A estrutura básica das estruturas condicionais IF e CASE estão apresentadas, respectivamente, nos Códigos 2.5 e 2.6. A linguagem PL/SQL também oferece suporte para três estruturas de repetição: no comando W hile, a condição é avaliada antes de entrar no laço; o comando Loop assegura que o bloco de comandos será executado pelo menos uma vez pois a condição é testada no meio do laço e, por
2.1. PROGRAMAÇÃO EM BANCO DE DADOS 24 fim, a instrução For realiza iterações sobre uma quantidade específica de vezes. Nos Códigos 2.7, 2.8 e 2.9, tem-se a estrutura básica do While, do Loop e do For, respectivamente (MURRAY,
2013).
Código 2.6: Estrutura básica da instrução Case na linguagem PL/SQL
CASE [expression]
WHEN condition_1 THEN result_1
WHEN condition_2 THEN result_2 ...
WHEN condition_n THEN result_n
ELSE result
END
/
Código 2.7: Estrutura básica da instrução While na linguagem PL/SQL
WHILE condition LOOP
-- sequence_of_statements
END LOOP;
/
Código 2.8: Estrutura básica da instrução Loop na linguagem PL/SQL
LOOP
-- sequence_of_statements
EXIT WHEN boolean_expression; END LOOP;
/
Código 2.9: Estrutura básica da instrução For na linguagem PL/SQL
FOR loop_counter IN [REVERSE] lowest_number..highest_number
LOOP
-- sequence_of_statements
END LOOP;
/
A linguagem PL/SQL possui quatro tipos de abstrações de dados: Cursor, Collections, Records e Data Type. O nome Cursor é dado para uma área privada e específica da linguagem PL/SQL a qual armazena informações para o processamento de um comando e possíveis resulta-dos obtiresulta-dos com a consulta associada. Três comanresulta-dos podem ser utilizaresulta-dos para manipulação de um Cursor: 1) a inicialização é realizada por meio do comando OPEN, o qual identifica o con-junto de resultados; 2) o comando FETCH é executado repetidamente para recuperar as linhas
2.1. PROGRAMAÇÃO EM BANCO DE DADOS 25 retornadas; e, 3) o comando CLOSE libera o espaço de memória utilizado (MURRAY,2013). A abstração de dados chamada Collections é um grupo ordenado de elementos que possuem o mesmo tipo de dados e, enquanto isso, a abstração chamada Records é formada por uma estrutura de dados composta por campos que podem conter diferentes tipos de dados (MURRAY,2013). Os tipos de Collections existentes na linguagem PL/SQL são: 1) tabelas aninhadas (i.e., nested table); 2) matriz de tamanho variável (i.e., varray); e, 3) tabelas indexadas (i.e., index by table) (MURRAY,2013). E, para Records, existem os tipos: 1) baseado em tabela; 2) baseado em cursor; e 3) definido pelo usuário, onde os dois primeiros tipos são declarados utilizando o atributo %ROW TY PE. E, por fim, o tipo de dados denominado Data Type é utilizado para indicar variáveis, constantes e parâmetros com tipos de dados primitivos da linguagem PL/SQL. A linguagem PL/SQL provê diversos tipos de dados previamente definidos como, por exem-plo: CHAR, NUMBER, DAT E, VARCHAR, entre outros. As estruturas básicas de um Cursor, Collections e Records estão representadas nos Códigos 2.10, 2.12 e 2.11, respectivamente.
Código 2.10: Estrutura básica de um Cursor na linguagem PL/SQL
-- cursor declaration:
CURSOR cursor_name IS SELECT_statement;
-- opening a cursor
OPEN cursor_name;
-- fetch a cursor:
FETCH cursor_name INTO variable_name;
-- closing a cursor:
CLOSE cursor_name;
/
Código 2.11: Estrutura básica do tipo de dados Records na linguagem PL/SQL
TYPE
type_name IS RECORD
(field_name1 datatype1 [NOT NULL] [:= DEFAULT EXPRESSION], field_name2 datatype2 [NOT NULL] [:= DEFAULT EXPRESSION], field_name3 datatype3 [NOT NULL] [:= DEFAULT EXPRESSION], ...
field_nameN datatypeN [NOT NULL] [:= DEFAULT EXPRESSION); record-name type_name;
2.1. PROGRAMAÇÃO EM BANCO DE DADOS 26 Código 2.12: Estrutura básica do tipo de dados Collections na linguagem PL/SQL
-- index-by table
TYPE type_name IS TABLE OF element_type [NOT NULL]
INDEX BY subscript_type;
table_name type_name;
-- nested table
TYPE type_name IS TABLE OF element_type [NOT NULL]; table_name type_name;
-- varray
TYPE type_name IS VARRAY(n) of element_type; table_name type_name;
/
Algumas instruções da linguagem PL/SQL são voltadas para as quatro operações básicas em banco de dados relacionais: inserção, atualização, remoção e busca de dados nas tabelas do banco de dados. O comando Insert insere uma ou mais linhas de dados em uma tabela do banco de dados. A instrução U pdate modifica os valores de colunas específicas em uma ou mais linhas em uma tabela do banco de dados. Para remover linhas inteiras de dados de uma tabela específica, existe o comando Delete. O comando Select é utilizado para recuperar dados de uma ou mais tabelas do banco de dados e esta instrução pode ser bem complexa. A estrutura básica dos comandos Insert, U pdate, Delete e Select estão apresentadas, respectivamente, nos Códigos 2.13, 2.14, 2.15 e 2.16.
Código 2.13: Estrutura básica da instrução Insert na linguagem PL/SQL
INSERT INTO table_name
(column1, column2, ... column_n)
VALUES
(value1, value2, ... value_n); /
Código 2.14: Estrutura básica da instrução Update na linguagem PL/SQL
UPDATE table_name
SET column1 = value1, column2 = value2, ...
column_n = value_n
2.2. ANÁLISE DE DOMÍNIO 27 Código 2.15: Estrutura básica da instrução Delete na linguagem PL/SQL
DELETE FROM table_name
[WHERE conditions];
/
Código 2.16: Estrutura básica da instrução Select na linguagem PL/SQL
SELECT [DISTINCT] expressions
[INTO {variable1, variable2... | record_name}]
FROM table_list
[WHERE conditions]
[GROUP BY group_by_list]
[HAVING search_conditions]
[ORDER BY order_list [ASC | DESC] ]
/
2.2 Análise de Domínio
O termo ”Análise de Domínio” no contexto do processo de analisar softwares relaciona-dos, foi inserido na literatura como uma definição para atividades com o intuito de identificar objetos e ações de um conjunto de sistemas que possuem um domínio em comum (NEIGHBORS,
1980). A análise de domínio de um so f tware é um processo de exploração sistemática para definir e investigar as funcionalidades e capacidades em comum de um conjunto de so f twares possuindo o mesmo domínio. Então, a disponibilidade de uma análise de domínio melhora o processo de desenvolvimento do so f tware, pois promove a reutilização do sistema (KANG et al.,
1990).
Por possuir uma boa documentação e facilidade de entendimento dos seus conceitos, neste trabalho é utilizada uma metodologia chamada Feature-Oriented Domain Analysis (FODA) para realização da Análise de Domínio (KANG et al.,1990). Esta metodologia, que fundamenta-se em um estudo de outras abordagens de Análise de Domínio, baseia-se em identificar as características que um usuário normalmente esperar encontrar em aplicações para um determinado domínio. Este método possui foco em determinar as diferenças e as similaridades dos so f twares de um mesmo domínio com uma hierarquia de características ( f eature model) constituído pelas características ( f eatures) ou propriedades do sistema que são relevantes (KANG et al.,1990).
A Análise de Características possui como objetivo principal a identificação das caracte-rísticas do sistema que são visíveis ao usuário final. A variação das caractecaracte-rísticas do sistema pode ser apresentada utilizando uma decomposição hierárquica de características. Na Figura 2.1 ilustra-se a decomposição hierárquica para o domínio Carro. Analisando o diagrama, pode-se per-ceber que um carro possui, obrigatoriamente, transmissão e potência, porém, o ar-condicionado
2.2. ANÁLISE DE DOMÍNIO 28 Figura 2.1: Exemplo de um Modelo de Características para o domínio Carro
Fonte: Adaptado de Kang et al. (1990)
é uma característica opcional. Além disso, a transmissão pode ser manual ou automática, mas, neste exemplo, um carro não pode ter os dois tipos de transmissão pois o diagrama apresenta como sendo uma característica alternativa. Características consideradas alternativas normalmente são apresentadas como sendo especializações de uma característica mais geral (KANG et al.,
1990). Pode-se identificar que uma característica é obrigatória ou opcional observando a ligação entre as funcionalidades ou por meio da cardinalidade apresentada. Percebe-se, na Figura 2.1, que a obrigatoriedade é apresentada com um círculo preenchido e a cardinalidade 1:1 enquanto que a funcionalidade opcional possui um círculo vazado e a cardinalidade 0:1.
Figura 2.2: Representações das funcionalidades da metodologia FODA
(a) Possíveis representações para o
operador lógico XOR (b) Possíveis representações para o operador lógico OR Fonte: O autor
Na metodologia FODA é possível representar funcionalidades que retratam os seguintes operadores lógicos: 1) XOR, chamada de funcionalidade alternativa; e 2) OR, chamada de funcionalidade OU. Essas duas características podem ser simbolizadas de mais de uma forma na hierarquia de características do FODA, como está apresentado na Figura 2.2. É importante ressaltar que as representações fornecem exatamente a mesma informação para quem estiver
2.3. LINGUAGEM VISUAL DE PROGRAMAÇÃO 29 observando as decomposições hierárquicas de um domínio (BONTEMPS et al.,2004).
A entrada de uma Análise de Domínio é o conhecimento do domínio, que pode ser obtido das mais diversas formas, como pode ser visto na Figura 2.3. Combinado com um método de Análise de Domínio, obtém-se a terminologia e conceitos do domínio em estudo, ou seja, uma lista de variação indicando a informação necessária para a especificação de uma instância do sistema e a definição das características em comum (OLIVEIRA,2010). No desenvolvimento deste trabalho, a metodologia FODA é utilizada para realizar a especificação e o detalhamento do domínio de rotinas de banco de dados utilizando a linguagem PL/SQL. Esta metodologia é bastante utilizada na literatura para análise de domínio de softwares e, por isso, possui boa documentação dos seus conceitos. Com isso, esta metodologia foi selecionada para realização da Análise de Domínio do presente trabalho.
Figura 2.3: Análise de Domínio
Fonte: (OLIVEIRA,2010)
2.3 Linguagem Visual de Programação
Uma Linguagem Visual de Programação (LVP) pode ser informalmente definida como sendo uma linguagem que usa alguma representação visual (ícones, grafos, diagramas ou figuras) em adição ou no lugar de textos e números, para representar o que teria de ser escrito em uma linguagem de programação tradicional unidimensional (CHANG; ICHIKAWA; LIGOMENI-DES,1986). Então, LVP é definida como sendo o uso de representação gráfica no processo de programação (NICKERSON,1994). A utilização de LVP é estimulada com as seguintes premissas: 1) em geral, as pessoas preferem imagens a textos; 2) como um meio de comunicação, as imagens são mais expressivas do que palavras, pois, é possível transmitir mais significado em uma única unidade de expressão; e 3) imagens não possuem as barreiras linguísticas que as linguagens naturais possuem de tal forma que é possível compreender uma LVP independente da língua falada pelo usuário (CHANG; ICHIKAWA; LIGOMENIDES,1986).
Os diagramas de so f tware são a base para todos os sistemas de programação visual. De acordo com Nickerson (1994), no contexto de LVP, os diagramas que retratam as associações
2.3. LINGUAGEM VISUAL DE PROGRAMAÇÃO 30 dos elementos podem ser divididos em três categorias: métricas, simbólicas e topológicas. As associações métricas estão relacionadas com distâncias medidas entre objetos. Neste caso, pode ser utilizada qualquer escala para mensurar a distância. As associações simbólicas possuem um modo mais geral de serem representadas que com o uso de descrições do tipo: link(a,b), onde qualquer diagrama pode ser inteiramente descrito simbolicamente como uma lista textual de nós e arestas. E, por fim, a mais comumente utilizada em sistemas é a classificação no espaço topológico (NICKERSON,1994), o qual é possível visualizar no diagrama como os elementos se relacionam entre si. Na categoria topológica, as associações podem acontecer nas seguintes formas:
⌅ Adjacência - Quando A e B são células que compartilham um lado ou possuem lados
sobrepostos;
⌅ Ligação - Quando os nós A e B são explicitamente ligados por uma aresta. Grafos e
árvores são formas de diagramas conhecidos que utilizam esta classificação;
⌅ Contenção - Quando um nó está contido dentro do outro. Este método é mais utilizado
para indicar relações estabelecidas, como em diagramas Venn; e
⌅ Híbrida: Combinação de duas ou mais associações mencionadas nos itens acima.
Figura 2.4: Classificação topológica de LVP
Fonte: (NICKERSON,1994)
Na Figura 2.4 apresenta-se exemplos dos tipos de associações na classificação topológica de uma LVP. A representação chamada de Adjacência possui um limite de conectividade e, por isso, normalmente é utilizada em esquemas simples. Isto é, representar uma grande quantidade de associações e/ou complexidade alta com este tipo de ligação resulta em diagramas complexos e de difícil entendimento. Como exemplo, o uso do comando break em estruturas de repetição e um grande número de estruturas condicionais aninhadas não são possíveis de serem representadas neste tipo de associação. Ao utilizar a representação Ligação, leva-se em conta o fato de que as arestas podem transmitir informações adicionais como, por exemplo, rótulos e direcionamento. Esta associação normalmente é utilizada em diagramas extensos e complexos devido a grande quantidade de informação que é possível transmitir com os relacionamentos entre os objetos. Por fim, a representação Contenção demonstra a relação estabelecidas entre os objetos no diagrama e, por isso, algumas estruturas podem ter um limite em sua representação. Por exemplo, estruturas recursivas são difíceis de serem representadas utilizando esta associação (NICKERSON,1994).
2.4. DESENVOLVIMENTO DE SOFTWARE DIRIGIDO POR MODELOS 31 Independente do tipo de associação utilizada, a LVP pode fazer uso de ícones para aumentar a expressividade da linguagem. Um ícone pode ser definido como uma representação gráfica de uma informação e é possível simbolizar um conceito a partir da sua utilização. O uso de ícones facilita o reconhecimento do conhecimento envolvido na linguagem e pode-se afirmar que ele é independente de idioma (MAITI et al.,2011).
2.4 Desenvolvimento de Software Dirigido por Modelos
Engenharia Dirigida a Modelo (do inglês, Model Driven Engineering - MDE) ( SCH-MIDT, 2006) é uma metodologia de desenvolvimento de so f tware que utiliza modelos de domínio em todas as fases de desenvolvimento. Estes modelos são representações abstratas dos conhecimentos relativos a um determinado domínio. MDE pode ser feito a partir de duas abor-dagens: Desenvolvimento Dirigido a Modelo (do inglês, Model Driven Development - MDD) e Arquitetura Dirigida a Modelo (do inglês, Model Driven Architecture - MDA) (SCHMIDT,
2006). A principal diferença entre as duas abordagens se concentra no fato da MDA ser uma proposta do Ob ject Management Group (OMG)1, que segue a notação de Linguagem de Mode-lagem Unificada (do inglês, Uni f ied Modeling Language - UML) (RUMBAUGH; JACOBSON; BOOCH,1999). Em contrapartida, na abordagem MDD é permitido utilizar qualquer notação. Então, com MDD, uma DSML é capaz de usar os padrões da OMG, mas não precisa seguir a sintaxe UML (LOPES et al.,2016). A relação entre as abordagens MDE, MDD e MDA está representada na Figura 2.5. Independente das diferenças entre as abordagens, elas são utilizadas para especificar linguagens de modelagem, regras para validar modelos e transformação de modelos (BRAMBILLA; CABOT; WIMMER,2012).
Figura 2.5: Hierarquia das abordagens MDE, MDA e MDD
Fonte: Adaptado de Brambilla; Cabot; Wimmer (2012)
No contexto de MDD, modelo é uma abstração de objetos do mundo real. Por sua vez, o metamodelo é a descrição dos conceitos de um modelo e como estes conceitos podem estar relacionados entre si (i.e., a sintaxe abstrata da linguagem) e é definido em uma linguagem de metamodelagem. Esta linguagem de metamodelagem, por sua vez, é uma linguagem superior
2.4. DESENVOLVIMENTO DE SOFTWARE DIRIGIDO POR MODELOS 32 que descreve novas linguagens de modelagem e também é definida com um metamodelo. O meta-modelo de uma linguagem de metamodelagem é chamado de meta-metameta-modelo (CETINKAYA; VERBRAECK,2011). Na Figura 2.6, apresenta-se o padrão de metamodelo do paradigma de MDD. Para validar os modelos, deve-se destacar que é possível existir combinações sintatica-mente válidas no metamodelo que, por razões de semântica estática, devem ser impedidas. Isto é, no intuito de determinar significado para certas construções sintaticamente corretas, é necessário definir restrições e/ou condições relativas ao uso dos seus elementos sintáticos (FIDALGO et al.,
2012). Tais regras podem ser definidas, por exemplo, em Linguagem de Limitação de Objetos (do inglês, Ob ject Constraint Language - OCL) (RICHTERS; GOGOLLA,1998), ou qualquer linguagem equivalente.
Figura 2.6: Padrão de metamodelo em MDD
Fonte: Adaptado de Cetinkaya; Verbraeck (2011)
O uso da metodologia MDD melhora o ciclo de vida do desenvolvimento de so f tware, oferecendo um nível superior de abstração para o desenvolvimento do sistema ( BALASUBRA-MANIAN et al.,2006). Este paradigma depende de (1) uma DSML e (2) das transformações dos modelos. Essas transformações são realizadas de modelos para artefatos específicos e podem ser de dois tipos: modelo para modelo (model to model - M2M), nesta transformação, um modelo é transformado em outro modelo e ambos estão de acordo com algum metamodelo; modelo para texto (model to text - M2T), nesta transformação, um modelo é transformado em texto (documentação) ou código (DEMIRLI,2012). Este método tem sido utilizado no de-senvolvimento de sistemas complexos de so f tware em larga escala em conjunto com a aplicação de uma DSML.
Uma DSML é uma linguagem de programação que oferece, por meio de um conjunto restrito de notações adequadas e abstrações, um poder de expressividade focado em um domínio específico (DEURSEN; KLINT; VISSER,2000). Às vezes, no entanto, uma DSML pode conter uma Linguagem de Propósito Geral (GPL) como uma sub-linguagem, oferecendo uma maior
2.4. DESENVOLVIMENTO DE SOFTWARE DIRIGIDO POR MODELOS 33 expressividade a um domínio específico, em acréscimo ao poder expressivo de uma GPL. DSML podem ser vistas como linguagens de especificação, bem como linguagens de programação (DEURSEN; KLINT; VISSER,2000).
Figura 2.7: Processo de desenvolvimento de DSML
Fonte: (CHO; GRAY; SYRIANI,2012)
O processo de desenvolvimento de uma DSML requer conhecimento no domínio do problema (CHO; GRAY; SYRIANI,2012). Normalmente, uma DSML é desenvolvida de forma incremental, iterando sobre as fases principais que estão apresentadas na Figura 2.7. A fase chamada Captura de Requisitos é responsável pela identificação do domínio do problema e o processo de elicitação dos requisitos. Nesta fase, é essencial que os especialistas do domínio identifiquem o que é esperado da linguagem e como são realizadas as representações deste domínio. Nas fases chamadas Definir Sintaxe Concreta, Definir Sintaxe Abstrata e Definir Semântica da Linguagem é esperado que os especialistas em desenvolvimento de linguagens realizem as seguintes etapas: 1) definição da sintaxe concreta - definição dos detalhes visuais da linguagem, i.e, a notação que será utilizada; 2) definição da sintaxe abstrata - é possível ser representada pelo metamodelo. Apresenta a descrição dos elementos da linguagem que está sendo definida, i.e, especificação do metamodelo que define os elementos da linguagem e como estes podem estar relacionados; e 3) definição semântica estática da linguagem: definição do significado das estruturas do sistema, i.e., o significado para cada elemento gráfico e as regras de boa formação que não estão capturadas pelo metamodelo. Isto é, que podem existir construções sintaticamente válidas pelo metamodelo mas que devem ser impedidas pois geram algum erro na geração de código (por exemplo, nomes de variáveis ausentes ou duplicados). E, por fim, na fase chamada Verificar Linguagem, os especialistas no domínio devem verificar a composição da DSML e fornecer comentários que podem levar a uma iteração que requer mais desenvolvimento. Esse processo de desenvolvimento se repete até que os especialistas
2.5. METODOLOGIA DE PESQUISA PARA A LINGUAGEM CRYSTAL 34 considerem a DSML satisfatória para o seu domínio e determinem o fim do desenvolvimento.
2.5 Metodologia de Pesquisa para a Linguagem Crystal
Com os conceitos apresentados neste capítulo, a metodologia de pesquisa apresentada na Seção 1.4 foi aplicada ao presente trabalho da forma como se segue:
⌅ Para a revisão da literatura, foram realizadas consultas pré definidas nas bases de
dados IEEE, ACM, Springer, Science Direct e Google Scholar. Os resultados das pesquisas foram analisados a partir do título e do abstract, com a intenção de descartar trabalhos que não possuam o escopo de visualização, criação e/ou manipulação de Blocos Anônimos, Procedimentos e Funções. Em adição a isto, as principais ferramentas comerciais de acordo com o ranking apresentado pela empresa Austrian IT Consulting2foram analisadas para identificação dos seus respectivos escopos. ⌅ O processo de design foi dividido em duas etapas: 1) o levantamento dos requisitos
com o uso da metodologia FODA; e, 2) definição da linguagem Crystal seguindo o processo de desenvolvimento de uma DSML apresentado na Figura 2.7. As regras de validação da linguagem foram definidas a partir de Murray (2013), para construções bem formadas na linguagem PL/SQL.
⌅ A avaliação da ferramenta CrystalCASE, desenvolvida para suportar a linguagem
aqui definida Crystal, foi realizada com exemplos para apresentar a expressividade da linguagem aqui proposta. Além disto, os exemplos foram utilizados para realizar comparações entre a ferramenta deste trabalho com as ferramentas presentes da literatura, com o intuito de identificar pontos fortes e fracos.
2.6 Considerações Finais
A linguagem PL/SQL é uma extensão da linguagem SQL, utilizada para manipular dados em bancos de dados relacionais que utilizam o SGBD Oracle. As rotinas e instruções SQL consideradas estão diretamente relacionadas com o poder de expressividade dessa linguagem. As estruturas da linguagem PL/SQL apresentadas neste capítulo são utilizadas na geração de código da ferramenta apresentada e desenvolvida neste trabalho.
Uma análise de domínio é um processo que investiga as funcionalidades e capacidades em comum de so f tware que possue um mesmo domínio. Este processo aumenta a qualidade do sistema e melhora o processo de desenvolvimento do mesmo. Uma metodologia bastante utilizada para este tipo de análise é chamada de FODA, que, por meio de um modelo de características determina as diferenças e similaridades do so f tware do domínio.
2.6. CONSIDERAÇÕES FINAIS 35 Linguagens Visuais de Programação utilizam representações gráficas para o processo de desenvolvimento de so f tware e possuem como base os diagramas. O tipo de associação mais utilizada nesses diagramas é a Ligação, no qual os nós A e B são explicitamente ligados por uma aresta. As LVP podem aumentar seu poder de expressividade ao utilizar ícones em sua definição.
Uma DSML é uma linguagem de programação que possui um domínio específico. Este tipo de linguagem permite validação de regras e otimização ao nível do domínio no qual é baseada. A metodologia de desenvolvimento chamada MDD faz uso de uma DSML para utilizar modelos de domínio em todas as fases do desenvolvimento do sistema. A seguir, no Capítulo 3, são discutidos trabalhos relacionados e critérios de avaliação que levam em consideração os conceitos aqui apresentados.
36 36 36
3
Revisão da Literatura
Neste capítulo, faz-se uma análise dos trabalhos relacionados e de ferramentas utilizadas no mercado que visam auxiliar a programação, de forma diagramática, de rotinas em banco de dados. Esta análise tem como critério de seleção trabalhos que permitam a visualização, criação e/ou manipulação de Blocos Anônimos, Procedimentos e/ou Funções. Trabalhos impor-tantes e conhecidos na literatura, tais como: VERGARA(1991),ABITEBOUL et al. (1997),
ALASHQUR; SU; LAM (1989) e GYSSENS; PAREDAENS; GUCHT (1990), auxiliam a programação de forma diagrámatica apenas de consultas para banco de dados utilizando SQL. Ou seja, esses trabalhos não dão suporte a visualização/criação/manipulação de rotinas de banco de dados e, por isso, foram excluídos desta análise. O restante deste capítulo está estruturado da seguinte forma: inicialmente, descreve-se os critérios para avaliação dos trabalhos relacionados. Em seguida, usando os critérios previamente definidos, os principais trabalhos e ferramentas rela-cionados a esta proposta são avaliados. Por fim, apresenta-se uma análise e avaliação consolidada destes trabalhos e ferramentas.
3.1 Características para Avaliação
Procurando efetuar uma análise equitativa dos trabalhos relacionados, a seguir são apresentados os critérios utilizados para avaliá-los. A classificação considera se um trabalho possui (4) ou não possui (6) cada critério. A união de todos estes critérios forma uma linguagem diagramática completa, na qual o usuário possui poder de escolha em suas definições, com informações visuais que facilitam o entendimento do desenvolvimento da rotina:
1. Cursor - identifica se existe uma funcionalidade na ferramenta para a declaração e manipulação de cursor no código PL/SQL;
2. If-Else - analisa se é possível implementar/utilizar instruções condicionais do tipo I f Else no código PL/SQL do sistema;
3. Case - verifica se o so ftware possui uma funcionalidade que dê suporte ao uso e à manipulação de instruções condicionais do tipo Case;
3.1. CARACTERÍSTICAS PARA AVALIAÇÃO 37 4. While - investiga se o sistema dispõe de uma funcionalidade que permita a utilização
de estruturas de repetição do tipo W hile no código PL/SQL;
5. Loop - identifica se é possível utilizar e criar estruturas de repetição do tipo Loop no so f tware;
6. For - analisa a possibilidade de manipular estruturas de repetição do tipo For na ferramenta;
7. Insert - verifica se o sistema permite o uso de comandos para inserção de dados em tabelas do banco de dados por meio do construtor Insert;
8. Update - identifica se no so ftware é possível realizar atualização de dados em tabelas do banco de dados por meio do comando U pdate;
9. Delete - investiga a capacidade do sistema de realizar exclusão de dados em tabelas do banco de dados por meio da instrução Delete;
10. Select - analisa o suporte do so ftware na utilização de instrução PL/SQL para seleção e filtro de dados de tabelas no código PL/SQL;
11. Exception - verifica se a ferramenta provê suporte ao tratamento de erro de código SQL, usando a seção Exception;
12. Collections - investiga a opção de declarar variáveis do tipo Collections no código SQL fornecido e/ou gerado pelo sistema;
13. Records - identifica se é possível utilizar variáveis do tipo Records no código SQL com suporte no so f tware;
14. Data Type - analisa o suporte da ferramenta à declaração de variáveis de diferentes tipos básicos, como CHAR, INT , DAT E, entre outros, no código SQL fornecido e/ou gerado na ferramenta;
15. Chamada a Procedimentos - verifica se existe uma funcionalidade na ferramenta que possibilite a chamada de Procedimentos que já se encontram armazenados no banco de dados;
16. Chamada a Funções - investiga se o sistema possibilita a chamada a Funções que estão armazenadas no banco de dados;
17. Construção de Bloco Anônimo - identifica se o trabalho/ferramenta em estudo fornece a possibilidade de modificar, editar e criar Blocos Anônimos para banco de dados;
3.2. TRABALHOS ACADÊMICOS 38 18. Construção de Procedimento - analisa se é possível construir, manipular e realizar modificações em Procedimentos para banco de dados, utilizando o trabalho/ferra-menta em estudo;
19. Construção de Função - verifica se o trabalho/ferramenta em estudo providencia a funcionalidade de criar, editar e manipular Funções para banco de dados;
20. Engenharia Reversa - identifica se o trabalho/ferramenta possui uma funcionalidade para gerar abstrações em alto nível para códigos na linguagem PL/SQL fornecidos como entrada para o sistema;
21. Engenharia Direta - categoriza se o trabalho/ferramenta em estudo permite a ge-ração de código na linguagem PL/SQL para abstrações de alto nível desenvolvidas utilizando o sistema proposto;
22. Classificação Topológica baseada em Ligação - classifica se o trabalho/ferramenta utiliza diagramas com associações baseadas em ligações. Conforme descrito na Seção 2.3, com este tipo de classificação é possível representar diagramas grandes e complexos;
23. Utilização de Ícones - verifica se o trabalho/ferramenta em estudo faz uso de ícones em sua LVP para aumentar o poder de expressividade da linguagem; e
24. Desenvolvimento Dirigido a Modelo - identifica se o trabalho/ferramenta foi cons-truído com a metodologia de desenvolvimento baseada em modelos, com especifica-ção da sintaxe concreta, sintaxe abstrata e semântica.
3.2 Trabalhos Acadêmicos
Nesta seção, faz-se uma análise dos trabalhos acadêmicos selecionados. Apesar de não ter sido realizada uma revisão sistemática, a triagem dos trabalhos aqui abordados foi realizada a partir de pesquisas nas bases de dados IEEE, ACM, Springer, Science Direct e Google Scholar. Fazendo uso de duas expressões: 1) ”(data f low OR f lowchart) AND0stored procedure0 AND SQL”; e, 2) ”(visual language database OR visual query database)”, uma análise foi realizada nos resultados, a partir do título e do abstract, com o intuito de descartar ferramentas e linguagens que não estivessem dentro do escopo de visualização, criação e/ou manipulação de Blocos Anônimos, Procedimentos e Funções.
3.2.1 Reis
O trabalho de Reis (2011) apresenta uma ferramenta para modelagem de Procedimentos para banco de dados. Utilizando elementos visuais, é possível realizar Engenharia Direta a partir
3.2. TRABALHOS ACADÊMICOS 39 da modelagem gráfica de Procedimentos e, com isso, obter o código equivalente na linguagem PL/SQL. Um grande diferencial da ferramenta é o auxílio para a construção do corpo de um Procedimento. O sistema proposto nesse trabalho é classificado como uma ferramenta CASE que é definida utilizando metamodelo, seguindo a metodologia MDD. Essa ferramenta auxilia o usuário na construção dos três principais componentes de um Procedimento: 1) área de definição dos parâmetros; 2) área para declaração de variáveis; e 3) o corpo. Entretanto, o sistema não possui suporte para Funções, pois o autor menciona essa estrutura como um possível trabalho futuro.
Figura 3.1: Exemplos de tela do trabalho proposto em Reis (2011).
(a) Exemplo de construção de uma consulta (b) Exemplo de construção do corpo de um Procedimento
Fonte: (REIS,2011)
É exibido na Figura 3.1 telas para ilustração do so f tware proposto nesse trabalho que está sendo analisado. Na Figura 3.1(a) apresenta-se um exemplo de como pode ser realizada a construção dos detalhes de uma consulta ao banco de dados por meio do construtor SELECT . Como se pode verificar, é possível selecionar colunas de tabelas armazenadas no banco de dados, atribuir apelidos (aliases) e definir condições simples para a consulta. A tela exibida na Figura 3.1(b) exemplifica a construção do corpo de um Procedimento com alguns construtores PL/SQL. Como se pode identificar neste exemplo, o corpo do Procedimento é composto por uma seção que representa a atribuição de uma expressão a uma variável (assign), uma instrução condicional (If-ElseIf-Else), três comandos de repetição (Loop, While e For) e uma instrução para abertura de um Cursor, que estão numerados indicando a ordem de execução.
A partir das imagens apresentadas, é possível identificar que as estruturas de dados utilizadas no so f tware não são definidas com o uso de ícones que sejam parte de uma Linguagem
3.2. TRABALHOS ACADÊMICOS 40 Visual de Programação. Cada construtor utilizado é identificado textualmente e todos os símbolos utilizados são iguais, apenas havendo variação na cor. Segundo a descrição das classificações topológicas apresentadas no Capítulo 2, pode-se concluir que a classificação utilizada por essa ferramenta é a chamada de Contenção, pois o diagrama apresenta construtores dentro de outros construtores. Ao longo do trabalho de Reis (2011), os seguintes construtores são mencionados como disponíveis para uso na ferramenta: Cursor, If-Else, While, Loop, For, Insert, Update, Delete, Select, Collections, Records e Data Type. Assume-se que a ferramenta não possui suporte para os construtores não mencionados diretamente no trabalho, tais como: Case, Exceptions, Chamada a Procedimentos, Chamada a Função e Construção de Função. No Quadro 3.1, apresenta-se uma análise deste trabalho.
Quadro 3.1: Avaliação do trabalho proposto em (REIS,2011). Características de Avaliação 4/ 6 Cursor 4 If-Else 4 Case 6 While 4 Loop 4 For 4 Insert 4 Update 4 Delete 4 Select 4 Exception 6 Collections 4 Records 4 Data Type 4 Chamada a Procedimentos 6 Chamada a Funções 6 Construção de Bloco Anônimo 6 Construção de Procedimento 4
Construção de Função 6 Engenharia Reversa 6 Engenharia Direta 4
Classificação Topológica baseada em Ligação 6 Utilização de Ícones 6
MDD 4
Fonte: Elaborado pela Autora (2017)
3.2.2 Tartir e Issa
A ferramenta SQLFlow (TARTIR; ISSA,2005) utiliza Engenharia Reversa para permitir a geração automática do fluxograma e gráfico de fluxo correspondente ao fluxo operacional de
3.2. TRABALHOS ACADÊMICOS 41 código de rotinas de bancos de dados fornecidas em arquivos de entrada. Esta ferramenta é construída com a arquitetura de so f tware MVC (Modelo - Visão - Controlador). O primeiro nível, a camada de visão, é responsável por averiguar a análise do código fonte e gerar os dia-gramas correspondentes. O nível intermediário, a camada do controlador, possui o componente responsável pela análise e interpretação da lógica de negócio. E o último nível, a camada de modelo, possui o componente de gerenciamento de arquivos.
Figura 3.2: Exemplo de uma rotina de entrada para a ferramenta SQLFlow
Fonte: (TARTIR; ISSA,2005)
O sistema dá suporte como entrada apenas a Blocos Anônimos escritos na linguagem PL/SQL. Os seguintes construtores são mencionados pelos autores como disponíveis para uso na ferramenta: Chamadas para Procedimentos, Chamada para Funções, Records, Collections, Data Type, If-Else, Case, Loop, For, While, Exception e comandos SQL (Insert, Delete, Update e Select). Assume-se que a ferramenta não possui suporte para os construtores não mencionados diretamente no trabalho, tais como: Cursor, Construção de Procedimento e Construção de Função. Com o intuito de ilustrar como a ferramenta SQLFlow funciona, na Figura 3.2 é exibido um exemplo de uma rotina fornecida como entrada para a ferramenta. Então, na Figura 3.3, os diagramas gerados para essa entrada estão apresentados: do lado esquerdo, apresenta-se o fluxograma gerado e do lado direito o gráfico de fluxo gerado é exibido. Nota-se que a seção de declaração de variáveis não está presente neste fluxo. A ferramenta identifica a palavra-chave begin como o início dos Blocos Anônimos no código PL/SQL e inicia o fluxograma a partir deste ponto. Os nós do grafo de fluxo correspondem a grupos indivisíveis de comandos PL/SQL e as linhas que conectam dois nós indicam que o segundo nó talvez seja executado imediatamente
3.2. TRABALHOS ACADÊMICOS 42 Figura 3.3: Diagramas gerados pela ferramenta SQLFlow.
(a) Fluxograma (b) Gráfico de fluxo
Fonte: (TARTIR; ISSA,2005)
depois do primeiro nó. Para ilustração, tem-se que: o nó de número 15 é a representação do comando For; o nó 16 é correspondente à mensagem existente dentro desta estrutura de repetição; o nó 17 representa a linha que indica o final da repetição - End Loop. Pelas linhas, percebe-se que o código pode passar ou não pelo nó de número 16, pois irá depender da condição do Loop.
Analisando as imagens apresentadas dessa ferramenta, percebe-se que são ilustrados diagramas que não utilizam ícones como parte de uma Linguagem de Programação Visual e que possuem, na classificação topológica, a associação chamada de Ligação. De acordo com os exemplos apresentados no trabalho (TARTIR; ISSA,2005), todos os construtores do código SQL estão representados por uma estrutura no diagrama. Além disso, não foi possível encontrar evidências no trabalho de que a metodologia MDD foi utilizada para o desenvolvimento do so f tware proposto. No Quadro 3.2, apresenta-se uma análise deste trabalho em relação aos critérios apresentados anteriormente.
3.2.3 Habringer e Pichler
O sistema proposto por Habringer; Moser; Pitchler (2014) utiliza a Engenharia Reversa para apresentar códigos PL/SQL com uma representação mais abstrata e abrangente. A ferra-menta utiliza Metamorphosis (KLAMMER; PICHLER,2014), um f ramework para análise de sistemas legados em domínios técnicos. Utilizando como dados de entrada códigos PL/SQL e um esquema de banco de dados com metadados sobre as tabelas e colunas, a ferramenta gera
3.2. TRABALHOS ACADÊMICOS 43 Quadro 3.2: Avaliação do trabalho proposto em Tartir; Issa (2005).
Características de Avaliação 4/ 6 Cursor 6 If-Else 4 Case 4 While 4 Loop 4 For 4 Insert 4 Update 4 Delete 4 Select 4 Exception 4 Collections 4 Records 4 Data Type 4 Chamada a Procedimentos 4 Chamada a Funções 4
Construção de Bloco Anônimo 4
Construção de Procedimento 6 Construção de Função 6 Engenharia Reversa 4
Engenharia Direta 6 Classificação Topológica baseada em Ligação 4
Utilização de Ícones 6
MDD 6
Fonte: Elaborado pela Autora (2017)
uma árvore de sintaxe abstrata especificada pela ASTM1, um metamodelo definido pela OMG. Com base nesta árvore abstrata, uma análise é realizada do fluxo de dados a partir dos dados de produção para os dados do resultado contendo mensagens de erro. Esta avaliação baseia-se na análise do fluxo de dados e na execução simbólica do código SQL. O resultado desta análise gera a representação de alto nível da ferramenta.
A ferramenta dá suporte como entrada a apenas procedimentos escritos na linguagem PL/SQL. Os seguintes construtores são mencionados pelos autores como disponíveis para uso na ferramenta: Cursor, Data Type, Collections, Records, If-Else, Case, Loop, For, While, Exception e comandos SQL (Insert, Delete, Update e Select). Assume-se que a ferramenta não possui suporte para os construtores não mencionados diretamente no trabalho, tais como: Chamada a Procedimentos, Chamada a Funções, Construção de Blocos Anônimos e Construção de Função. Visando apresentar um exemplo de utilização do sistema, na Figura 3.4(a) mostra-se um exemplo de código PL/SQL fornecido como entrada para o sistema. Nota-se que são descritos dois comandos de inserção de dados Insert , dois comandos de atualização de dados U pdate
