Uma linguagem de modelagem e uma ferramenta CASE para apoiar o projeto lógico de banco de dados relacionais

Uma Linguagem de Modelagem e uma Ferramenta CASE

para apoiar o Projeto Lógico de Banco de Dados Relacionais

Recife

2017

Uma Linguagem de Modelagem e uma Ferramenta CASE

para apoiar o Projeto Lógico de 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 Universidade Federal de Per-nambuco como requisito parcial para obtenção do grau de Mestre em Ciência da Computação.

Orientador: Prof. Dr. Robson do Nascimento Fidalgo

Recife

Catalogação na fonte

Bibliotecário Jefferson Luiz Alves Nazareno CRB 4-1758

F363l Fernandes, Lúcio Alves.

Uma linguagem de modelagem e uma ferramenta CASE para apoiar o projeto lógico de banco de dados relacionais / Lúcio Alves Fernandes . – 2017.

104 f.: fig., tab.

Orientador: Robson Nascimento Fidalgo.

Dissertação (Mestrado) – Universidade Federal de Pernambuco. CIn. Ciência da Computação, Recife, 2017.

Inclui referências e apêndice.

1. Banco de dados. 2. Projeto Lógico. 3. Metamodelo. I. Fidalgo, Robson Nascimento. (Orientador). II. Titulo.

Lúcio Alves Fernandes

Uma Linguagem de Modelagem e uma Ferramenta CASE para

apoiar o Projeto Lógico de Banco de Dados Relacionais

Dissertação 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 Profissional em 15 de setembro de 2017.

Aprovado em: 15 / 09 / 2017.

BANCA EXAMINADORA

__________________________________________ Prof. Luciano de Andrade Barbosa

Centro de Informática / UFPE

__________________________________________ Prof. Cláudio de Souza Baptista

Universidade Federal de Campina Grande

__________________________________________ Prof. Robson do Nascimento Fidalgo

Centro de Informática / UFPE (Orientador)

e projeto físico. O projeto conceitual é a primeira etapa no processo de construção do sistema de BD e tem a função de criar o esquema conceitual. O esquema conceitual tem o papel de especificar os objetos e as relações entre os mesmos que são relevantes ao sistema deBDque está sendo implementado. O projeto lógico consiste em transformar o esquema conceitual em um esquema lógico através do mapeamento das estruturas presentes no esquema conceitual utilizando um modelo de dados de implementação. Um modelo de implementação comumente utilizado é o Modelo Relacional, que implementa o BD como um conjunto de relações. Já o projeto físico visa definir qual Sistema de Gerenciamento de Banco de Dados (SGBD) será utilizado, além de questões sobre controle de acesso, armazenamento e otimização. Entretanto, embora as fases do projeto de um sistema deBDsejam claramente definidas, o projeto lógico é muitas vezes poluído com elementos de outras fases. Por exemplo, informações sobre cardinalidade de relacionamentos e regras de acesso são comumente encontradas no esquema lógico. Desta forma, buscou-se na literatura metamodelos que fizessem a distinção dos conceitos pertinentes as diferentes etapas do projeto de um sistema deBDrelacional. Um metamodelo é projetado com base no paradigma Model Driven Development (MDD), cujo maior benefício é a especificação de modelos executáveis. Isto é, diagramas que abstraem a complexidade da sintaxe de uma linguagem computacional e são usados por ferramentas do tipo Computer Aided Software Engineering (CASE) para gerar, automaticamente, código executável ou interpretável. No entanto, as soluções encontradas - Common Warehouse Metamodel (CWM) e Information Management Metamodel (IMM) -, não fazem uma distinção entre conceitos relacionados ao projeto lógico e físico, além de não darem suporte à criação de ferramentasCASE. Desta forma, visando sanar os problemas apresentados, este trabalho propõe uma linguagem de modelagem, baseada em

MDDcom foco no domínio do Modelo Relacional para construção do projeto lógico. Visando validar a proposta e proporcionar uma aplicação dos elementos utilizados pelo metamodelo, foi desenvolvida a ferramenta RMMCASE, uma ferramentaCASEque dá suporte aos elementos da linguagem de modelagem. Além disso, foi criado um projeto lógico de exemplo que explora todos os elementos propostos, a fim de certificar a expressividade e viabilidade deste trabalho. Como resultado, pode-se constatar que o trabalho proposto apresenta um metamodelo expressivo e uma notação gráfica simplificada e que contempla os conceitos do Modelo Relacional.

Palavras-chave: Desenvolvimento Dirigido por Modelo. Projeto lógico. Metamodelo.

The design of aBDis divided into three stages: conceptual design, logical design and physical design. The conceptual design is the first step in the process of constructing the BDsystem and has the function of creating the conceptual schema. The conceptual schema has the role of specifying the objects and the relationships between them that are relevant to theBDsystem being implemented. The logical design consists of transforming the conceptual schema into a logical schema by mapping the structures present in the conceptual schema using an implementation data model. A commonly used implementation model is the Relational Model, which implements theBDas a set of relations. The physical project defines whichSGBDwill be used, as well as storage, backup and optimization issues. However, while the design phases of aBDsystem are clearly defined, logical design is often polluted with elements from other phases. For example, information about cardinality of relationships, user groups, access rules can often be found in the logical schema. In this way, it was sought in literature to make the distinction of the relevant concepts the different stages of the design of a relationalBDsystem. A metamodel is designed based on the Model Driven Development (MDD) paradigm, whose greatest benefit is the specification of executable models. That is, diagrams that abstract the complexity of the syntax of a computational language and are used by Computer Aided Software Engineering (CASE) tools to automatically generate executable or interpretable code. However, the solutions found -CWM

andIMM- do not distinguish between concepts related to logical and physical design, nor do they support the creation ofCASEtools. In this way, in order to solve the presented problems, this work proposes a modeling language based onMDDand focusing on the domain of the Relational Model for the construction of the logical project. In order to validate the proposal and provide an application of the elements used by the metamodel, the RMMCASE tool was developed, aCASE

tool that supports the elements of the modeling language. In addition, a logical example project was created that explores all the proposed elements in order to certify the expressiveness and feasibility of this work. As a result, it can be seen that the proposed work presents an expressive metamodel and a simplified graphical notation that contemplates the concepts of the Relational Model.

Figura 1 – Relação Estudante e seus elementos . . . 18

Figura 2 – A relação Carro com duas chaves candidatas: Emplacamento e Numero_serie 21 Figura 3 – Características do domínio Compras Online através da modelagem Feature Oriented Domain Analysis (FODA) . . . 24

Figura 4 – Representação do processo de criação de modelos . . . 26

Figura 5 – Processo de transformação de modelos . . . 27

Figura 6 – Exemplo de transformação Model-To-Text (M2T): Classe para código Java . 28 Figura 7 – Os três principais elementos de uma DSML e suas relações . . . 29

Figura 8 – Eclipse Modeling Framework (EMF) - Classes do pacote ECore . . . 30

Figura 9 – CWM: Schema e seus objetos . . . 34

Figura 10 – CWM: Tabelas, Colunas e tipo de dados . . . 35

Figura 11 – IMM: Metaclasses de Tabela e Coluna . . . 36

Figura 12 – IMM: Definição Database Instance e Schema . . . 37

Figura 13 – Exemplificação da notação de Elsmari&Navathe . . . 39

Figura 14 – Exemplificação da notação de Silberschatz . . . 40

Figura 15 – Diagrama IE . . . 42

Figura 16 – Exemplificação da notação IDEF1X . . . 43

Figura 17 – Hierarquia de Características do Esquema Relacional . . . 47

Figura 18 – Hierarquia de Características que representam os atributos, domínios e tipos de dados . . . 48

Figura 19 – Hierarquia de Características das Restrições . . . 49

Figura 20 – Relation e Attribute . . . 50

Figura 21 – Sintaxe concreta das Constraints . . . 51

Figura 22 – Assertion e Domain . . . 51

Figura 23 – Ligação entre relações . . . 52

Figura 24 – Exemplificação dos relacionamentos e violação de integridade . . . 52

Figura 25 – Relational MetaModel (RMM) - Schema, Domain, Relation e SchemaConstraint 53 Figura 26 – RMM - Constraints . . . 53

Figura 27 – RMM - Domain . . . 55

Figura 28 – RMM - Relation . . . 56

Figura 29 – Metamodelo RMM . . . 57

Figura 30 – Representação de um erro Sintático . . . 58

Figura 31 – Modelagem de Projeto Lógico de EMPRESA utilizando o RMMCASE . . . 62

Figura 32 – Wizard de criação de novo projeto . . . 63

Figura 35 – Construtor do objeto Assertion e suas propriedades . . . 66

Figura 36 – Construtor do objeto Domain e suas propriedades . . . 66

Figura 37 – Construtor do objeto Check e suas propriedades . . . 67

Figura 38 – Construtor do objeto Relation e suas propriedades . . . 67

Figura 39 – Construtor do objeto Attribute e suas propriedades . . . 68

Figura 40 – Construtor do objeto Primary Key e suas propriedades . . . 69

Figura 41 – Construtor do objeto Unique Key e suas propriedades . . . 69

Figura 42 – Construtor do objeto Foreign Key e suas propriedades . . . 70

Figura 43 – Construtor do objeto Trigger e suas propriedades . . . 71

Figura 44 – RMMCASE: Exemplo da sintaxe EVL . . . 72

Figura 45 – RMMCASE: Validação do Esquema Lógico . . . 72

Figura 46 – RMMCASE: Sinalização de erro semântico . . . 73

Figura 47 – RMMCASE: Geração de código Structured Query Language (SQL) . . . . 74

Figura 48 – RMMCASE: Geração de código SQL. . . 74

Figura 49 – RMMCASE: Geração de notação textual . . . 75

Figura 50 – RMMCASE: Representação de esquema lógico através da notação textual . 76 Figura 51 – RMMCASE: Importação do postgreSQL . . . 76

Figura 52 – RMMCASE: Configuração de conexão com o BD . . . 77

5.1 Trecho de código EGL . . . 73

A.1 Metamodelo ECore na linguagem textual emfatic . . . 83

A.2 Regras de validação Semântica do metamodelo . . . 86

A.3 SQL gerado pela RMMCASE . . . 91

A.4 Código EGL da Trasnformação para Notação Textual . . . 93

Tabela 1 – Tabela dos atributos da relação Estudante e seus respectivos domínios. . . . 19

Tabela 2 – Tabela dos conceitos suportados pela notação Elsmari&Navathe(2011). . . . 39

Tabela 3 – Tabela dos conceitos suportados pela notação de Silberschatz . . . 41

Tabela 4 – Tabela dos conceitos suportados pela notação IE. . . 42

Tabela 5 – Tabela dos conceitos suportados pela notação IDEF1X . . . 44

Tabela 6 – Tabela comparativa das notações: Elsmari&Navathe, Silberschatz, IE e IDEF1X 45

Tabela 7 – Tabela comparativa das notações: Elsmari&Navathe, Silberschatz, IE, IDEF1X e RMM . . . 78

BD Banco de Dados

CASE Computer Aided Software Engineering

CWM Common Warehouse Metamodel

DSML Linguagem de Modelagem Específica de Domínio

IDE Integrated Development Environment

IDEF1X Integration Definition for Information Modeling

EVL Epsilon Validation Language

EGL Epsilon Generation Language

ER Entidade-Relacionamento

EMF Eclipse Modeling Framework

EMP Eclipse Modeling Project

FODA Feature Oriented Domain Analysis

GMF Graphical Modeling Framework

GMP Eclipse Graphical Modeling Project

GMT Graphical Modeling Tool

IE Information Engineering

ISO International Organization for Standardization

IMM Information Management Metamodel

MDD Model Driven Development

M2T Model-To-Text

M2M Model-To-Model

OCL Object Constraint Language

SQL Structured Query Language

1 INTRODUÇÃO . . . . 14 1.1 Motivação . . . 15 1.2 Objetivos . . . 16 1.3 Estrutura da dissertação . . . 16 2 FUNDAMENTAÇÃO TEÓRICA . . . . 18 2.1 Modelo Relacional . . . 18 2.1.1 Restrições Básicas . . . 19 2.1.2 Restrições de Integridade . . . 21 2.1.3 Restrições Avançadas . . . 22

2.1.4 Tratamento de Violação de Restrição . . . 23

2.2 Feature-Oriented Domain Analysis - FODA . . . 23

2.3 Desenvolvimento Orientado a Modelo . . . 25

2.3.1 Transformações de modelo . . . 25

2.3.2 Linguagens de Modelagem Específicas de Domínio . . . 28

2.4 Ferramentas de Modelagem para MDD . . . 29

2.4.1 Eclipse Modeling Framework - EMF . . . 29

2.4.2 Graphical Modeling Framework - Graphical Modeling Framework (GMF) . 30 2.4.3 Epsilon . . . 31

2.5 Considerações Finais . . . 31

3 TRABALHOS RELACIONADOS . . . . 33

3.1 Modelos e Metamodelos para o modelo relacional . . . 33

3.1.1 Common Warehouse Metamodel - CWM . . . 33

3.1.2 Information Management Metamodel - IMM . . . 34

3.2 Notações Gráficas . . . 37

3.2.1 Notação de Elmasri e Navathe (2015) . . . 38

3.2.2 Notação de Silberschatz . . . 39

3.2.3 Information Engineering - IE . . . 41

3.2.4 IDEF1X . . . 42

3.3 Considerações Finais . . . 44

4 UMA LINGUAGEM DE MODELAGEM PARA O PROJETO LÓGICO DE BANCO DE DADOS RELACIONAL. . . . 46

4.1 Captura de Requisitos . . . 46

4.5 Considerações Finais . . . 59

5 FERRAMENTA RMMCASE . . . . 61

5.1 Desenvolvimento da ferramenta RMMCASE . . . 61

5.2 Exemplo de uso . . . 62 5.3 Utilização da ferramenta . . . 62 5.3.1 Assertion . . . 65 5.3.2 Domain. . . 65 5.3.3 Check . . . 66 5.3.4 Relation . . . 67 5.3.5 Attribute . . . 68 5.3.6 Primary Key . . . 68 5.3.7 Unique Key . . . 68 5.3.8 Foreign Key . . . 68 5.3.9 Trigger . . . 70

5.4 Verificação do esquema lógico . . . 71

5.5 Componente Geração de Esquema sql . . . 73

5.6 Recurso de Notação Textual . . . 74

5.7 Importação de Esquema . . . 75 5.8 Considerações Finais . . . 77 6 CONCLUSÃO. . . . 79 6.1 Considerações Finais . . . 79 6.2 Contribuições . . . 80 6.3 Trabalhos Futuros . . . 80 REFERÊNCIAS . . . . 81

APÊNDICE A – METAMODELO RMM, REGRAS DE VERIFICAÇÃO E CÓDIGOS DA FERRAMENTA CASE . . . . 83

O desenvolvimento orientado a modelos - do inglês Model Driven Development (MDD) - é uma abordagem de desenvolvimento de software, na qual os modelos são considerados os principais artefatos do processo de desenvolvimento (BRAMBILLA; CABOT; WIMMER,2012). Uma de suas vantagens é poder expressar modelos usando conceitos independentes dos detalhes de implementação, ou seja, abstraem a complexidade da sintaxe de uma linguagem computacional. Além disso, os modelos são definidos para um domínio de problema específico, o que os torna mais fáceis de especificar, entender e manter (SELIC,2003). As operações executadas sobre modelos são implementadas através de transformações que podem ser de modelo para modelo (Model-To-Model (M2M)) ou de modelo para texto (M2T) (BRAMBILLA; CABOT; WIMMER,

2012).

Através do MDD, pode-se criar um modelo que descreve modelos, denominado Me-tamodelo. Assim, um metamodelo constitui, basicamente, a definição de uma linguagem de modelagem, uma vez que define uma maneira de descrever todas as classes de modelos que podem ser representados pela mesma (BRAMBILLA; CABOT; WIMMER,2012). O uso de meta-modelos permite formalizar as informações de um domínio, sendo ainda extensível e reutilizável. Outra vantagem é a capacidade de definir esquemas semânticos para troca e armazenamento de dados, além de facilitar processos de automatização que utilizam múltiplos modelos.

FerramentasCASEsão utilizadas para auxiliar o desenvolvimento de determinadas tarefas a partir de um computador. Elas são amplamente utilizadas para a elaboração de projetos de

BD em todas as suas fases (HEUSER,2009). O uso da abordagem MDDpermite a criação de ferramentas CASE robustas, devido às vantagens de reuso e interoperabilidade, inerentes aos metamodelos. Além disso, as ferramentas CASEutilizam um outro aspecto doMDD: as Linguagem de Modelagem Específica de Domínio (DSML). Esta linguagem de diagramação oferece poder de expressividade a um domínio específico (DEURSEN; KLINT; VISSER,2000). AsDSMLs são implementadas por ferramentasCASE, que podem ajudar a detectar erros com antecedência (SANTOS,2017). UmaDSMLé composta por três elementos: a sintaxe abstrata, a sintaxe concreta e a semântica estática. A sintaxe abstrata representa o metamodelo enquanto a sintaxe concreta representa a notação gráfica utilizada na ferramenta, ou seja, os elementos gráficos que representam os objetos do metamodelo. Por fim, o papel da semântica estática é definir como esses modelos devem ser interpretados, assim como suas restrições (BRAMBILLA; CABOT; WIMMER,2012).

O projeto de um sistema deBDé um processo compreendido por três fases: 1) Projeto Conceitual, 2) Projeto Lógico e 3) Projeto Físico. A primeira fase visa descrever quais os requisitos de dados dos usuários e como oBDdeverá ser estruturado para atender estes requisitos

(SILBERSCHATZ; KORTH; SUDARSHAN,2011). Esta fase normalmente utiliza o modelo Entidade-Relacionamento (ER), um modelo de dados que trata dos objetos e as relações entre os mesmos utilizando elementos gráficos para criar um esquema conceitual. A segunda fase do processo, o projeto lógico, faz o mapeamento dos objetos e das relações descritos no esquema conceitual para seus elementos correspondentes, dentro do modelo de dados de implementação escolhido. Este modelo de implementação define qual o paradigma (Relacional, Orientado a Objeto, Modelo Entidade Relacionamento, Semi-estruturado, grafo, chave-valor, dentre outros) será utilizado para criar o esquema lógico doBD. Um modelo de implementação amplamente utilizado para este fim é o Modelo Relacional, o qual trata os elementos projetados como um conjunto de relações. Além disso, é bem difundido e bastante utilizado, tendo uma ampla literatura disponível:Elmasri e Navathe(2015),Silberschatz, Korth e Sudarshan(2011),Connolly e Begg

(2005),Date(2003),Harrington(1998). SegundoCoronel, Morris e Rob(2011) o projeto físico, a última fase do projeto, é o processo de determinar a organização de armazenamento de dados e as características de acesso a dados do BD, a fim de garantir sua integridade, segurança e desempenho. ParaConnolly e Begg(2005), o principal objetivo do projeto físico é descrever como implementar fisicamente o projeto lógico. Assim, é no projeto físico que se definem os índices utilizados para alcançar o acesso eficiente aos dados, os caminhos de acesso e parâmetros físicos do projeto para o arquivo deBD. Esta fase de projeto é realizada como base em umSGBD

específico.

1.1

Motivação

O projeto lógico relacional é muitas vezes poluído com elementos de outras fases. Por exemplo, muitas vezes, a cardinalidade de relacionamento é incluída no projeto lógico, mas deveria aparecer somente no projeto conceitual. No projeto lógico relacional, as cardinalidades do esquema conceitual deveriam ser expressas através de outros elementos como: 1) chave estrangeira sem restrição de unicidade e obrigatoriedade para cardinalidades 1:N com participação parcial; 2) chave estrangeira com restrição de unicidade e obrigatoriedade para cardinalidades 1:1 com participação total e 3) nova relação com chave primária igual a composição das chaves estrangeiras para cardinalidades N:N. Um outro exemplo é que, embora o projeto lógico seja elaborado tendo em mente um modelo de dados de umSGBD, é apenas no projeto físico que o mesmo é definido (CONNOLLY; BEGG,2005).

Neste contexto, dado que um metamodelo define os conceitos de um domínio e como estes podem ser relacionados, buscou-se na literatura metamodelos que definissem de forma clara os conceitos pertinentes ao projeto lógico de umBDrelacional. Existem os metamodelos

CWM(OMG,2003) eIMM(OMG,2005) que trazem um pacote dedicado ao Modelo Relacional, porém, não ocorre uma distinção entre conceitos relacionados ao projeto lógico e físico. Por exemplo, os metamodelos citados incluem a configuração de segurança do banco e controle

notações gráficas para dar suporte ao projeto de um sistema de BDe foi identificado que as notações encontradas não conseguem expressar de forma clara os conceitos: restrição de domínio, restrição not null, check, operação e violação de restrição e restrições semânticas. Outro ponto é que nem todas as notações expressam de forma clara o relacionamento entre as relações.

Desta forma, dado que não há um metamodelo que trate o projeto lógico de forma independente das outras fases do projeto de um sistema deBD; que as notações gráficas muitas vezes não conseguem expressar os conceitos do Modelo Relacional de forma clara e completa; o desenvolvimento deste trabalho é motivado por desconhecer a existência de outro trabalho que defina um metamodelo utilizando abordagemMDDa fim de criar umaDSMLque permita a construção de projeto lógico de umBDrelacional.

1.2

Objetivos

O objetivo geral desta pesquisa é definir uma linguagem de modelagem para apoiar o projeto lógico deBDs, segundo o Modelo Relacional, e uma ferramentaCASEpara dar suporte a esta linguagem. Para alcançar esse objetivo geral, alguns objetivos específicos são necessários tais como:

1. Identificar o domínio do Modelo Relacional para o projeto lógico;

2. Definir uma notação gráfica para o projeto lógico;

3. Definir um metamodelo para o projeto lógico através da abordagemMDD;

4. Especificar restrições para validação de semântica estática do projeto lógico;

5. Desenvolver uma ferramentaCASEpara dar suporte ao metamodelo, a notação gráfica e as restrições de validação propostos.

1.3

Estrutura da dissertação

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 envolvidas no desenvolvimento deste trabalho. Ocapítulo 3traz uma avaliação dos trabalhos relacionados aos conceitos básicos apresentados. Ocapítulo 4apresenta, detalhadamente, os elementos construídos para dar suporte ao metamodelo. Nocapítulo 5são mencionadas e evidenciadas as particularidades da ferramenta desenvolvida para validar o metamodelo, estabelecendo, ao final uma avaliação comparativa com trabalhos relacionados. Nocapítulo 6, são apresentadas a conclusão, as principais contribuições,

bem como a indicação de trabalhos futuros para continuidade da pesquisa realizada. Por fim, Apêndice A apresenta o metamodelo, regras de verificação e códigos dos recursos adicionais da ferramenta CASE.

Neste capítulo, são apresentados os principais conceitos que norteiam esta pesquisa. Inicialmente, serão apresentados os conceitos do Modelo Relacional, os princípios da metodologia

FODA, os conceitos fundamentais do MDDe ferramentas de modelagem para a abordagem

MDD. Por fim, serão apresentadas as considerações finais deste capítulo.

2.1

Modelo Relacional

O modelo relacional é um modelo de dados amplamente utilizado pelosSGBDs comerci-ais. Proposto porCodd(1970), o modelo possui uma forte base matemática e usa um conjunto de relações para representar oBD, as quais são baseadas na teoria dos conjuntos e no conceito de relação matemática.

Um dos objetivos do Modelo Relacional é permitir um alto nível de independência entre os dados. Assim, aplicações não são afetadas por modificações na representação interna dos dados, seja na organização dos arquivos, ordem dos registros ou caminho de acessos ( CON-NOLLY; BEGG,2005). Desta forma, o modelo relacional torna-se uma abordagem atraente, sendo popularmente utilizado na elaboração do projeto lógico de umBD. No entanto, a utilização eficiente do Modelo Relacional requer a compreensão de alguns conceitos importantes, os quais são definidos a seguir.

Estudante

Cpf Endereco Tel_emp Gpa

NULL 22 3,55 NULL 28 4,00 Sara Eduarda Bruna Martins 672.780.114-26 (81) 3912-7076 R. Guarabira. 719 (81) 3597- 0083 20 2,65 24 3,50 NULL (81) 3687- 9377 24 3,00

Nome Tel_res Idade

Cauã Francisco Nascimento 616.705.964-00 (81) 2618-3035 Barros Pinangé. R. Gerson de 984 Luna Bianca Maria Costa 287.548.814-71 (81) 3597-9283

R. Professor Mário Ramos;

816

Henrique Diogo Rocha 903.746.534-02 (81) 2984-1926 R. Douradina. ₆₆₇ (81) 2618-3030 Anthony Erick Almeida 086.309.604-26 R. João Pessoa; ₉₀₀

Nome da Relação Atributos

Tu

p

la

s

Figura 1 – Relação Estudante e seus elementos

Fonte: Adaptado de (ELMASRI; NAVATHE,2015).

Principal conceito do Modelo Relacional, uma relação constitui uma tabela bidimensional composta por colunas e linhas, identificadas por um nome (ELMASRI; NAVATHE,2015). Uma relação normalmente descreve um objeto do mundo real que deve ser armazenado dentro doBD, como exemplo, a figura1traz uma relação denominada Estudante e seus elementos.

Os atributos de uma relação representam os dados mais relevantes do objeto armazenado noBD. Seguindo ainda o exemplo da figura1, a relação apresentada contém os seguintes atributos: Nome, Cpf, Tel_res, Endereco, Tel_emp, Idade e Gpa. Outra característica dos atributos é que estes devem estar sempre relacionados a um domínio.

Segundo Elmasri e Navathe (2015), um domínio representa um conjunto de valores atômicos. O processo de especificação de um domínio passa por atribuir um nome ao mesmo, além de definir de qual tipo de dado os valores do domínio serão retirados. É possível ainda incluir na especificação do domínio um formato para o mesmo. Por exemplo, o domínio do atributo Cpf da relação Estudante, tem como nome CadastroPessoaFísica. Este domínio é composto por uma sequência de números no formato nnn.nnn.nnn-nn. Vale ressaltar que outras informações podem ser fornecidas para melhor interpretação do domínio. Como exemplo, o domínio PesoPessoas pode incluir a unidade de medida grama ou quilograma. A tabela1mostra os atributos da relação Estudante e seus respectivos domínios.

Tabela 1 – Tabela dos atributos da relação Estudante e seus respectivos domínios.

Atributo Nome do Domínio Descrição Definição do Domínio

Nome Nomes O conjunto de valores possí-veis para nomes válidos.

caractere: tamanho 50

Cpf CadastroPessoaFísica Conjunto de possíveis valo-res para CPF’s válidos.

caractere: valores 0-9, formato nnn.nnn.nnn-nn Tel_res Telefones Conjunto de números

telefô-nicos fixos válidos

caractere: valores 0-9, formato (nn) nnnn-nnnn Endereco Endereços Conjunto de valores

possí-veis para endereços válidos

caractere: tamanho 50

Tel_emp Telefones vide Tel_res vide Tel_res Idade Idades Possíveis valores para idade inteiro Gpa MédiaEstudante Conjunto de valores para a

média GPA dos estudantes

decimal: 3 dígitos, valo-res 0,00 - 5,00

Outro conceito importante é o conceito de tupla. Uma tupla é matematicamente uma lista ou sequencia finita de elementos. No caso do Modelo Relacional, uma tupla é composta pelos valores dos atributos que pertencem à linha, como pode ser visualizado na figura1. Desta forma, uma relação também pode ser entendida como um conjunto de tuplas. Além dos conceitos apresentados acima, o Modelo Relacional traz outros tópicos importantes. A próxima seção discute os tipos de restrições básicas presentes no Modelo Relacional como definidos porElmasri e Navathe(2015).

2.1.1 Restrições Básicas

As restrições básicas do Modelo Relacional são as seguintes: 1) restrição de domínio, 2) restrição de chave, e 3) restrição NOT NULL. As restrições de domínio especificam que dentro

Por exemplo, O atributo Idade da relação Estudante, apresentado na figura1, só assume valores numéricos. Caso assumisse um valor do tipo caractere (a, b, c, d etc.) seria uma violação da restrição de domínio (ELMASRI; NAVATHE,2015).

Por outro lado, as restrições de chave se baseiam na premissa relacional de que não podem existir duas tuplas iguais (ELMASRI; NAVATHE,2015). Neste sentido, uma chave compreende um subconjunto dos atributos A de uma relação R qualquer, para o qual essa regra de unicidade é válida sempre. Existem também outros subconjuntos dos atributos de uma relação, chamados de Superchave, que possuem a mesma restrição de unicidade. Para definir o que é uma chave, é necessário primeiro compreender o conceito de Superchave. A superchave é um subconjunto dos atributos de uma relação, o qual não existe a mesma combinação de valores para mais de uma tupla. Toda relação possui ao menos uma superchave que é o conjunto de todos os atributos da relação (ELMASRI; NAVATHE,2015). Assim, toda chave K de uma relação R é uma superchave de R. Uma chave possui ainda uma característica extra: caso um atributo A seja removido do conjunto K, isso resulta em um novo conjunto K’ que não é uma superchave de R. Uma chave é determinada a partir de seu significado e suas propriedades não podem ser violadas mesmo após a inserção de uma nova tupla. As propriedade de uma chave K qualquer, são definidas por

Elmasri e Navathe(2015):

1. Duas tuplas não podem ter o mesmo valor para todos os atributos na chave K. Isto também vale para as superchaves.

2. A chave K é uma superchave mínima, ou seja, caso a remoção de um atributo A da chave resulte em uma nova chave K’ que viole a propriedade 1. Esta propriedade não é exigida para as superchaves.

Considerando a relação Estudante da figura1como exemplo, o conjunto {Cpf} é uma chave e superchave de Estudante, uma vez que não pode haver mais de um estudante com o mesmo CPF. Logo, qualquer conjunto que inclua {Cpf} é uma superchave da relação Estudante. Por exemplo, {Cpf, Nome, Idade} é uma superchave. Isso se dá porque ao remover Nome, Idade ou ambos, o resultado ainda é uma superchave (no caso {Cpf}), o que não invalida a característica de chave mencionada acima.

O Modelo Relacional pode ter mais de um chave. Nesse caso, cada uma das chaves K de uma relação R são chamadas de chave candidata. Na figura 2, a relação Carro possui duas chaves candidatas: Emplacamento e Numero_serie, uma vez que dois carros não podem ter o mesmo emplacamento ou o mesmo número de série. O mesmo não pode ser afirmado sobre os atributos: Montadora, Modelo ou Ano, uma vez que todos violam as propriedades de uma chave (ELMASRI; NAVATHE,2015). A chave primária é designada a partir das chaves candidatas e é utilizada para identificar as tuplas da relação. Por convenção, os atributos que designam a

chave primária são apresentados com um underline, como pode ser visto na figura2. Quando uma relação possui mais de uma chave candidata, o processo de escolha da chave primária deve dar preferência as chaves com um único atributo ou àquela com o menor número de atributos (ELMASRI; NAVATHE,2015). Já as chaves únicas são as outras chaves candidatas que não fazem parta da chave primária. Na figura2, foi escolhida a chave candidata Emplacamento como chave primária da relação Carro, nesse caso, Numero_serie será uma chave única.

Figura 2 – A relação Carro com duas chaves candidatas: Emplacamento e Numero_serie

Fonte:Elmasri e Navathe(2015).

O valor NULL é usado para representar valores de atributos que podem ser desconhecidos ou não aplicáveis a uma determinada tupla. Por exemplo, na figura1, o atributo Tel_emp apresenta valores NULL, isso significa que o estudante não possui telefone comercial conhecido. Assim, a restrição NOT NULL especifica se determinado atributo permite valor NULL ou não. Utilizando como exemplo a figura1, o atributo Nome deve apresentar um valor válido e não NULL enquanto Tel_res e Tel_emp podem assumir um valor NULL (ELMASRI; NAVATHE,2015). É possível determinar também que um atributo assuma um valor específico, quando este valor é omitido em uma nova tupla. Este tipo de comportamento é conhecido como valor default. Porém, caso um valor default não seja especificado, o valor NULL é assumido como padrão.

Já a restrição do tipo Check pode restringir os valores de atributo ou domínio. Por exemplo, pode-se criar restrição que limita os carros permitidos na relação Carro da figura2, àqueles que sejam de um determinado grupo de montadoras. Assim, pode-se criar um Check para restringir os valores permitidos para o atributo Montadora, impedindo de carros de outras montadoras sejam inseridos na relação.

2.1.2 Restrições de Integridade

As restrições de integridade são aplicadas aoBDrelacional com o intuito de garantir a validade dos estados das relações (ELMASRI; NAVATHE,2015). As restrições de integridade compreendem dois tipos: restrição de integridade de entidade e restrição de integridade referencial. A restrição de integridade de entidade impede que uma chave primária tenha valor NULL. Isto ocorre porque, como já foi discutido na Seção anterior, uma chave primária tem o papel

propriedade de ser válida (ELMASRI; NAVATHE,2015). Diferente da restrição de entidade, que é aplicada individualmente sobre relações, as restrições de integridade referencial aplicam-se sobre duas relações (ELMASRI; NAVATHE,2015), mantendo a consistência entre as tuplas nas duas relações. O objetivo é garantir que uma tupla da relação R1 só possa referenciar a uma

outra tupla da relação R2 caso ela exista. A definição formal de uma restrição de integridade

referencial depende da conceituação de Chave estrangeira (ELMASRI; NAVATHE,2015). Dadas duas relações R1e R2, a chave estrangeira (FK) é o conjunto de atributos de R1

que referencia a relação R2, desde que satisfaça as seguintes regras:

1. Os atributos em FK têm o mesmo domínio que os atributos da chave primária (PK) de R2.

2. Um valor de FK em uma tupla t1 de R1, ocorre ou como um valor de PK de um tupla t2 de

R2ou NULL. No primeiro caso, diz-se que t1referencia (ou refere-se a) t2.

Assim, pode-se dizer que R1 é a relação que referencia e R2 a relação referenciada.

Desde que as duas propriedades citadas sejam verdadeiras, é possível afirmar que a restrição de integridade referencial está mantida. Vale ressaltar que uma relação R1 pode referenciar a si

mesma.

2.1.3 Restrições Avançadas

Embora as restrições apresentadas consigam modelar muitos dos requisitos de umBD, o Modelo Relacional oferece outras restrições para atender questões mais particulares. As restrições semânticas são restrições que emergem do domínio do problema e não se encaixam em nenhuma das restrições discutidas até aqui. As restrições semânticas representam, de modo geral, as regras do negócio e devem ser especificadas através de mecanismos fornecidos peloBD(ELMASRI; NAVATHE,2015). Por exemplo, as restrições semânticas podem ser implementadas para atender a seguinte restrição: a soma de todos os totais dos empréstimos para cada agência deve ser menor do que a soma de todos os saldos das contas na agência. Para implementar esta restrição, podem ser utilizados os seguintes mecanismos: Assertion ou Trigger (ELMASRI; NAVATHE,2015).

Assertion é um mecanismo utilizado para checar se determinada condição é verdadeira, ou não, para todas as tuplas de uma relação R. Na eventual violação da restrição, neste caso durante uma inserção ou atualização, a operação é rejeitada (ELMASRI; NAVATHE,2015).

O Trigger, por sua vez, permite que restrições semânticas sejam implementadas e checadas toda vez que determinados eventos ocorrerem, sendo possível escolher se o trigger será ativado antes ou depois do evento ocorrer. Os eventos estão normalmente ligados a três operações básicas de umBD: inserir, excluir e atualizar. Na implementação de um trigger, define-se que a ação será

tomada quando certos eventos ocorrem e quando certas condições são satisfeitas (ELMASRI; NAVATHE,2015).

2.1.4 Tratamento de Violação de Restrição

Como discutindo anteriormente, o Modelo Relacional apresenta diversas restrições, a fim de garantir a validade dos dados armazenados noBD. Entretanto, operações realizadas no

BDpodem violar as restrições definidas durante o projeto. Existem três operações básicas em umBDrelacional: inserir (insert), excluir (delete) e atualizar (update).

Durante uma operação Inserir, a inclusão de uma nova tupla na relação pode violar todas as restrições já apresentadas. Por exemplo, atributos incompatíveis com o domínio; chave primária NULL; chave estrangeira inválida; etc. OSGBDrejeitará a operação e apresentará um erro (ELMASRI; NAVATHE,2015).

SegundoElmasri e Navathe(2015), a operação Excluir consiste em remover uma tupla da relação. Esta operação pode incorrer no risco de violar a restrição de integridade referencial, uma vez que a tupla removida pode estar sendo referenciada por outras tuplas. Assim, para estes casos, o projetista pode definir qual comportamento deve ser adotado quando estas violações ocorrerem. Existem opções de comportamento disponíveis, caso uma operação de exclusão seja violada, são elas: 1) restrict, 2) cascade, 3) set null e 4) set default. Ao definir que uma operação Excluir se comporte no modo restrict, oSGBDrejeita qualquer operação que viole as restrições definidas. Já o cascade propaga a operação, removendo as tuplas que referenciavam a tupla que está sendo removida. O set null (ou set default), modificar o atributo que referencia a tupla removida para o valor NULL (ou um valor padrão válido) (ELMASRI; NAVATHE,2015).

De modo geral, ao atualizar uma tupla, pode-se violar uma restrição de domínio. No entanto, quando os atributos que serão modificados fazem parte da chave primária ou da chave estrangeira, outras violações podem ocorrer. O tratamento destas segue o comportamento seme-lhante ao da operação Excluir. Uma operação de Atualizar no modo restrict, força o SGBDa rejeitar qualquer operação que viole as restrições definidas. No cascade, quando um dos atributos faz parte da chave estrangeira, oSGBDatualiza todas as tuplas que se referenciam ao mesmo. Já no set null (ou set default), oSGBDmodifica o atributo que referencia a tupla atualizada para o valor NULL (ou um valor padrão válido) (ELMASRI; NAVATHE,2015).

2.2

Feature-Oriented Domain Analysis - FODA

Feature-Oriented Domain Analysis(FODA) é uma metodologia fundamentada em estudos de abordagens de análise de domínio, a qual visa obter e representar informação sobre sistemas de software que compartilham um conjunto semelhante de funcionalidades (KANG et al.,1990).

contexto e do domínio sendo analisado.

A metodologiaFODAobjetiva incorporar os elementos produzidos no processo de análise de domínio ao processo de desenvolvimento de software (KANG et al.,1990). Este método consiste em criar um modelo de características (feature model) constituído pelas características (features), ou propriedades do sistema que são relevantes (OLIVEIRA,2010).

A Análise de Características é o processo responsável pela geração do modelo que tem o papel de identificar as características que o usuário espera encontrar em aplicações de um determinado domínio (KANG et al.,1990). Além disso, o modelo criado neste processo serve como principal meio de comunicação entre usuários e desenvolvedores. Este processo objetiva ainda identificar as características do sistema que são visíveis ao usuário final (SANTOS,2017).

Observa-se, a partir da figura3, um modelo de características para o domínio Compras Online, que apresenta a representação hierárquica estabelecida entre os elementos que compõem o processo de compra. As ligações com círculos vazados indicam características opcionais, enquanto os preenchidos as obrigatórias. Tem-se ainda as ligações do tipo Ou (OR) e Ou Exclusivo (XOR), presentes nas características Pagamento e Segurança respectivamente. A relação de Pagamento com suas sub-características - Transferência Bancária e Cartão de Débito - é uma ligação do tipo Ou. Este tipo de ligação indica que uma ou mais das sub-características podem ser escolhidas. Já na característica Segurança, tem-se uma ligação do tipo Ou Exclusivo que indica que apenas uma das sub-características - Alta e Padrão - pode ser escolhida.

Figura 3 – Características do domínio Compras Online através da modelagemFODA

Fonte: Próprio autor

A análise de domínio tem como produto o conhecimento do domínio, que é obtido através de diversas fontes (SANTOS,2017). SegundoOliveira(2010), é a partir da análise de domínio que se obtém uma lista de variações, 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 dentro do domínio estudado. Assim, neste pesquisa o FODA é utilizado para realizar a especificação e o detalhamento do domínio do Modelo Relacional.

2.3

Desenvolvimento Orientado a Modelo

SegundoBrambilla, Cabot e Wimmer(2012), o desenvolvimento orientado a modelo (MDD), ou desenvolvimento dirigido a modelo, consiste em um abordagem de desenvolvimento que utiliza o modelo como principal artefato em todas as fases do projeto. Formalmente, um modelo é a representação seletiva de informações referentes a um aspecto específico de um sistema (OMG,2014). A principal vantagem doMDDé poder expressar modelos usando conceitos menos vinculados a detalhes de implementação, além do fato de os modelos serem mais próximos do domínio do problema, o que os torna mais fáceis de se especificar, entender e manter (SELIC,

2003). Para Silva(2015), os modelos vão além de mera documentação, tornando-se objetos executáveis uma vez que o modelo seja criado. Esses objetos podem então gerar códigos, serem compilados ou até mesmo interpretados para a execução. Desta forma, o MDDse utiliza da abstração para remover ou esconder detalhes que tornam a compreensão do modelo complexa, a fim de gerar uma representação do domínio do problema de fácil entendimento (SIVONEN,

2008).

Neste contexto, o modelo é uma abstração dos fenômenos e objetos do mundo real, e o metamodelo é uma descrição dos conceitos do modelo e como estes conceitos podem ser relacionados (SILVA,2015). De acordo comBrambilla, Cabot e Wimmer(2012), este processo de modelagem pode ocorrer de forma recursiva: definem-se os modelos e a partir destes os meta-modelos; e partir dos metamodelos os meta-metamodelos. Neste caso, o metamodelo descreve os modelos iniciais enquanto o meta-metamodelo é a descrição dos próprios metamodelos. A figura4, a seguir, apresenta um exemplo do processo de definição dos modelos e suas relações. De acordo com a figura4, M0 representa o objeto real do qual se abstrai o modelo M1. A partir de M1, abstrai-se um segundo modelo, M2 (metamodelo) que, por sua vez, permite a criação de um terceiro modelo, M3 (meta-metamodelo), que o descreve. Para Silva(2015), embora seja possível definir níveis infinitos de metamodelos, na prática, meta-metamodelos podem ser definidos com base em si mesmos não sendo então necessário ir além deste nível de abstração.

2.3.1 Transformações de modelo

A transformação do modelo é o processo de conversão de um modelo para outro modelo do mesmo sistemaOMG(2014). SegundoBrambilla, Cabot e Wimmer(2012), as transformações de modelo também é um elemento crucial da abordagemMDD, e permite a definição de mapeamento entre diferentes modelos.

EmMDD, as transformações podem ser tanto Model-To-Model (M2M) quanto Model-To-Text (M2T): no primeiro, as entradas e saídas são um ou mais modelos, já no último as entradas são modelos enquanto as saídas são uma representação textual do modelo (BRAMBILLA; CABOT;

Figura 4 – Representação do processo de criação de modelos

Fonte:Brambilla, Cabot e Wimmer(2012).

WIMMER,2012). O processo de transformação utiliza uma Linguagem de Transformação de Modelo, que define as regras do processo e estabelece se o processo é uni- ou bidirecional. Exemplos de linguagem de transformação incluem: ATL, Operational QVT e Relational QVT paraM2M; e Epsilon Generation Language (EGL) paraM2T(DEMIRLI,2012;KOLOVOS et al.,2017).

Na figura5, é apresentado o processo de transformaçãoM2M, em que um modelo de entrada é transformado em um modelo de saída, o qual pode ser tanto de um metamodelo distinto (como na figura5) quanto do mesmo metamodelo do modelo de entrada. As transformaçõesM2M

são uma importante ferramenta para facilitar a geração de modelos de software intermediários e, ao mesmo tempo, manter a consistência entre modelos (DEMIRLI,2012). A transformação de um modelo de origem para um de destino deve ser definida de tal forma que o modelo de destino deve estar em conformidade com o metamodelo de destino.

Na transformaçãoM2T, o processo segue estrutura parecida com a apresentada na figura5. No entanto, ao invés de um modelo de saída, tem-se uma representação textual do modelo de entrada, que pode ser uma documentação do modelo, um template, ou até mesmo um código executável. A figura6exemplifica o processo de transformação de um modelo que representa uma Classe em Java para seu código fonte correspondente. O modelo de Classe na figura6está em conformidade com o metamodelo que representa a estrutura de uma classe em Java. Assim,

Figura 5 – Processo de transformação de modelos

Fonte: Adaptado deDemirli(2012).

através de regras de transformação definidas por meio de uma Linguagem de Transformação de Modelo, cria-se o código fonte Java correspondente ao modelo utilizado como entrada.

Diagam de Classe Transformação de _{Modelo (M2T)} Linguagem de Transformação de Modelo para Texto

Código Java Modelo de entrada Linguagem utilizada Saída Metamodelo UML Conforme

Figura 6 – Exemplo de transformaçãoM2T: Classe para código Java

Fonte: Próprio autor

2.3.2 Linguagens de Modelagem Específicas de Domínio

SegundoBrambilla, Cabot e Wimmer(2012), Linguagem de Modelagem Específica de Domínio (DSML), são ferramentas conceituais que permitem a especificação de pensamentos e a conceituação da realidade de forma explícita. ADSML, como o próprio nome indica, é criada para atender um domínio específico. Para Cho, Gray e Syriani (2012),DSMLs aumentam o nível de abstração ao mesmo tempo que mantêm o espaço de modelagem reduzido ao domínio trabalhado.

SegundoDeursen, Klint e Visser(2000), umaDSMLé uma linguagem de programação ou linguagem de especificação executável que oferece, através de notações e abstrações apropriadas, um poder de expressividade a um domínio específico. Todavia, umaDSMLpode conter uma Linguagem de Propósito Geral (GPL) como sublinguagem, oferecendo uma maior expressividade ao domínio trabalhado, em acréscimo ao poder expressivo de uma GPL (SANTOS,2017).

De acordo comBrambilla, Cabot e Wimmer(2012), umaDSMLé composta por três importantes aspectos: sintaxe abstrata, sintaxe concreta e semântica estática. O papel da sintaxe abstrata é descrever as estruturas da linguagem e como as diferentes primitivas podem ser combinadas. Em outras palavras, a sintaxe abstrata é o metamodelo daDSML, representando os elementos da linguagem e como estes podem estar relacionados (SANTOS,2017). Já a sintaxe concreta descreve as representações específicas da linguagem, abrangendo codificação e, até mesmo, questão de aparência visual, podendo ser tanto gráfica quanto textual. A sintaxe concreta representa a notação utilizada pela linguagem. É a sintaxe concreta que normalmente o designer se reporta quanto está criando um modelo através de umaDSML. Por fim, a semântica estática descreve o significado dos elementos definidos na linguagem e o significado das diferentes formas que esses podem ser combinados. A semântica estática define ainda as regras de boa formação que não são capturadas pelo metamodelo (SANTOS,2017). A figura7apresenta estes elementos

e como interagem: pode-se verificar como a semântica estática dá significado tanto para as estruturas da sintaxe abstrata quanto da concreta.

Figura 7 – Os três principais elementos de uma DSML e suas relações

Fonte:Brambilla, Cabot e Wimmer(2012).

Em MDD, a sintaxe abstrata representa o metamodelo, enquanto a sintaxe concreta representa a notação gráfica da linguagem. Assim, o papel da semântica estática é definir como estes modelos devem ser interpretados, assim como suas restrições e contradições. Por exemplo, cabe à semântica estática garantir que não existam relações sem nome ou sem uma chave primária.

2.4

Ferramentas de Modelagem para MDD

Esta pesquisa utiliza as ferramentas de modelagem fornecidas pelo Projeto de Modelagem Eclipse (ECLIPSE,2016), além do framework Epsilon (KOLOVOS et al.,2017). O projeto de modelagem Eclipse consiste em um conjunto de tecnologias, frameworks e padrões de imple-mentação de forma unificadas, a fim de facilitar os processosMDD(ECLIPSE,2016). Dentre os frameworksdisponíveis, destacam-se oEMF(ECLIPSE,2016) e oGMF Eclipse(2016), os quais são destinados, respectivamente, ao desenvolvimento de metamodelos e à criação de editores gráficos para a geração de ferramentasCASE(SOUZA,2011). O Epsilon, por sua vez, consiste em um conjunto de linguagens e ferramentas destinadas ao gerenciamento de metamodelos. As próximas Seções serão dedicadas à discussão dos frameworks mencionados.

2.4.1 Eclipse Modeling Framework -EMF

OEMFconsiste em um framework focado na construção de ferramentasCASEe outras aplicações baseadas em modelos de dados estruturadosEclipse(2016). Este framework utiliza

chaves: EClass, EAttribute e EReference (SOUZA,2011). Enquanto a EClass é utilizada para representar uma metaclasse, o EAttribute é utilizado para representar um atributo de uma EClass, e o EReference representa associações entre EClass. Na figura8são apresentadas as classes do pacote Ecore e seus relacionamentos. Além do ECore, oEMFainda apresenta dois componentes fundamentais: oEMF.Edit e oEMF. Codegen, os quais são responsáveis, respectivamente, pela codificação de editores para os modelosEMFe pela geração de editores completos paraEMF

(incluindo interface gráfica)Eclipse(2016).

EClass name:String 0..* eSuperTypes EAttribute name:String EDataType name:String EReference name:String containment:boolean lowerBound:int upperBound:int eAttributeType 1 0..* eAttributes eReferences 0..* eOpposite 1 eReferenceType 1

Figura 8 –EMF- Classes do pacote ECore

Fonte:Steinberg et al.(2008).

SegundoSouza(2011), oEMFainda dá suporte a três níveis de geração de código. O nível Modelo fornece classes de interface e de implementação para todos os elementos do metamodelo da ferramentaCASE. Já o nível Adaptador gera as classes de implementação capazes de adaptar as metaclasses do metamodelo, enquanto o nível Editor é responsável por produzir a estrutura básica das metaclasses do metamodelo que serão utilizadas na etapa de geração do editor gráfico noGMF, framework que será discutido a seguir (SOUZA,2011).

2.4.2 Graphical Modeling Framework -GMF

O frameworkGMFpossui ferramentas que facilitam a criação de editores gráficos para modelos definidos através doEMF(conforme secção §2.4.1). O desenvolvimento de editores gráficos utilizando oGMF, segundoSouza(2011), deve seguir os seguintes passos a saber: 1) importação do metamodelo de domínio definido através doEMF; 2) definição dos elementos

gráficos que serão exibidos na ferramentaCASE, assim, para cada metaclasse do metamodelo de domínio é definido um elemento gráfico; 3) determinação dos elementos que estarão disponíveis na paleta do editor; 4) definição do mapeamento entre as metaclasses do metamodelo de domínio, os elementos gráficos e os elementos da paleta de ferramentas; e 5) processamento do modelo gerador da ferramentaCASEjuntamente com o código-fonte do metamodelo e dos elementos gráficos do editor.

2.4.3 Epsilon

SegundoKolovos et al. (2017), o Epsilon Framework é uma família de linguagens e ferramentas para geração de código, transformações, validação, comparação, migração e re-fatoração de modelos. O Epsilon fornece várias linguagens e suas respectivas ferramentas de desenvolvimento são baseadas em Eclipse. As linguagens suportadas por esse framework são:

• Epsilon Object Language (EOL); • Epsilon Validation Language (EVL);

• Epsilon Transformation Language (ETL); • Epsilon Comparison Language (ECL); • Epsilon Merging Language (EML); • Epsilon Wizard Language (EWL); • EGL.

Dentre essas linguagens, esta pesquisa se utiliza, especificamente, daEVLe daEGL. O primeiro provê facilidades para a especificação de restrições para avaliar o modelo, enquanto o segundo fornece os mecanismos necessários para a transformaçãoM2T.

2.5

Considerações Finais

O projeto de umBDcompreende um processo divido em três etapas: 1) projeto conceitual, 2) projeto lógico e 3) projeto físico e, como apresentado neste capítulo, cada uma dessas etapas traz como produto um esquema que representa oBDem vários níveis de abstração.

Por sua vez, o Modelo Relacional é um modelo de dados utilizado para representação dos dados de um projeto lógico doBD. Seu principal objetivo é garantir a independência entre os dados e suas representações. Neste capítulo, abordou-se os principais conceitos do Modelo Relacional como relações, tupla, chave primária e as diversas restrições.

funcionalidades semelhantes. Além disso, os métodos de análise buscam formas de representar esses dados de maneira relevante e de fácil entendimento. Neste capítulo foram discutidos o métodoFODAe seus processos, o qual utiliza de um modelo de características para representar as funcionalidades convergentes e divergentes dentro de um domínio.

OMDDse utiliza de modelos como principais artefatos de um projeto. Estes modelos representam as abstrações dos fenômenos e objetos do mundo real. Existem também os modelos que descrevem modelos, chamado de metamodelos, que têm o papel de descrever os modelos iniciais e como estes interagem. Além disso, a abordagemMDDpermite a transformação de um modelo para outro ou de um modelo para uma representação textual do mesmo. Uma outra ferramenta utilizada no projetoMDDé aDSML. Trata-se de uma linguagem de programação utilizada para expressividade a um dado domínio, que permite criar uma notação gráfica capaz de expressar os artefatos e modelos do domínio trabalhado, de acordo a seu metamodelo.

O projeto Eclipse oferece uma gama de ferramentas para dar suporte a projetos de

MDD. Neste capítulo, discutiu-se as ferramentasEMFeGMF, que são frameworks utilizadas respectivamente, para definição de metamodelos e a criação de ferramentasCASE, a partir do metamodelo criado. Além disso, foi apresentado o Epsilon, um framework que traz um conjunto de linguagens e ferramentas utilizadas para validação e transformação de modelos, entre outras coisas.

No próximo Capítulo, serão apresentados os trabalhos relacionados que estão ligados a esta pesquisa.

3 TRABALHOS RELACIONADOS

Neste capítulo, faz-se uma análise de trabalhos relacionados a esta pesquisa, que oferecem suporte para a modelagem deBDs relacionais. Assim, serão discutidos alguns conceitos sobre os MetamodelosCWMe oIMM. Além disso, serão analisadas as notações gráficas presentes no trabalho deElmasri e Navathe(2015), a utilizada porSilberschatz, Korth e Sudarshan(2011), a Information Engineering(IE) e a IDEF1X (NIST,1993). Por fim, apresenta-se uma análise e avaliação consolidada destes trabalhos.

3.1

Modelos e Metamodelos para o modelo relacional

Como esta pesquisa tem como foco o projeto lógico de umBDrelacional, discute-se neste tópico o metamodeloCWMe seu sucessor, oIMM. OIMMé uma proposta de revisão da especificaçãoCWM, que é voltada para a troca de metadados (FIDALGO et al.,2013). Vale ressaltar que na terminologia formal do modelo relacional, Tabela é chamada de Relação, assim como uma Coluna é chamada de AtributoElmasri e Navathe(2015). Dessa forma, as palavras Tabela e Coluna são usadas na secção §3.1para referenciar a Relação e o Atributo respectivamente, seguindo o padrão adotado nos metamodelosCWMeIMM.

3.1.1 Common Warehouse Metamodel -CWM

CWM(OMG,2003) é uma especificação da OMG, a qual possui como um dos principais objetivos definir um metamodelo que pode ser usado para permitir o intercâmbio entre aplicações baseadas em Data Warehouse. Esse metamodelo consiste de uma série de sub-metamodelos que representam metadados de armazém comuns nas principais áreas de interesse para Data Warehousee Business Intelligence. Dentre eles, encontra-se o pacote Relational, que descreve os conceitos do modelo relacional baseado no padrãoSQL. OCWMserá discutido neste trabalho, visto que seu metamodelo define conceitos ligados à abordagem relacional. Nesta Seção, apresenta-se algumas metaclasapresenta-ses do metamodelo Relational para análiapresenta-se da conformidade com os conceitos discutidos na secção §2.1.

Na figura9, são apresentadas as metaclasses que descrevem o Schema1 e o Catálogo de Schemas, assim como suas hierarquias e composições. Observa-se que um catálogo contém Schemas, os quais são compostos por NamedColumnSets que podem representar Tabelas físicas, visões lógicas (Views) ou resultados de consultas aoBD. Além disso, um Schema pode conter Índices (SQLIndex), funções e/ou procedimentos (Procedure), além de gatilhos (Trigger). Pode-se

1 _{Um Schema neste contexto representa o conjunto de todas as Relações e seus atributos que compõem a base de}

físico de umBD, por exemplo, a definição da metaclasse SQLIndex.

Figura 9 –CWM: Schema e seus objetos

Fonte:OMG(2003).

Pode-se notar, a partir da análise da figura10que uma Coluna (Column) está associada a um tipo (SQLDataType) que pode ser um tipo simples (SQLSimpleType) ou um tipo distinto (SQLDistinctType). Os tipos SQLSimpleType são definidos pelo padrãoSQL, no entanto, alguns

SGBDs relacionais podem implementar tipos extras; já o tipo distinto (SQLDistinctType) pode ser definido a partir de um tipo simples. Uma coluna também pode possuir uma ou mais restrições de domínio (CheckConstraint), que podem ser aplicadas também à Tabela (Table), de acordo com o metamodelo.

O pacote Relational ainda define um conjunto de metaclasses para restrições de chaves primárias e estrangeiras. No entanto, oCWMnão contempla o conceito de Assertion tratado na secção §2.1. Além disso, traz os elementos Catalog, Collation, Character Set, Index, SQLDatatype e Temporary Table que vão além da modelagem lógica. Outro ponto é que, assim comoIMM, que será abordado na próxima Seção, o foco doCWMé a intercomunicação entre sistemas distintos e não a construção de ferramentasCASE, a qual é um dos objetivos deste trabalho.

3.1.2 Information Management Metamodel -IMM

OIMM(OMG,2003) é um metamodelo padrão, desenvolvido pela OMG, para atender às necessidades de gerenciamento de informações. Foi especificado para ser o sucessor do metamodelo CWM e ainda está em estágio de aprovação Request For Proposal (RFP). Esta especificação traz um conjunto de metamodelos, dentre esses, o Relational que especifica os princípios básicos do modelo relacional. Uma visão de alguns conceitos do metamodelo IMM Relationalé apresentada através da figura11e figura12.

Figura 10 –CWM: Tabelas, Colunas e tipo de dados

Fonte:OMG(2003).

Na figura11é apresentada a implementação de uma Tabela (Table) e alguns dos seus elementos relacionados. A tabela é uma coleção de um ou mais colunas e pode ser do tipo Base Tableou Derived Table. Uma Base Table pode ser representada por uma tabela física (Persistent Table), armazenada permanentemente no BDou temporária (Temporary Table) apenas para atender a um propósito particular e, em seguida, ser removida. A Derived Table é uma tabela derivada direta ou indiretamente de uma ou mais tabelas através de uma expressão de consulta. Esta pode ser expressa por uma Visão (Views) do resultado de uma consulta, ou de uma Visão Materializada (Materialized View), na qual os resultados de uma consulta são armazenados para uso futuro. Além disso, pode-se observar que a coluna, parte da estrutura da tabela, pode ser exatamente definida por um tipo específico de dados (Data Type).

Figura 11 –IMM: Metaclasses de Tabela e Coluna

Fonte:OMG(2005).

Na figura12 é apresentado um exemplo de como o metamodelo define instância de

BD(Database Instance), Esquema (Schema) e seus elementos relacionados. Observa-se que a instância de umBDé uma implementação física de um sistema de gerenciamento de dados e cada uma pode ser composta por um ou mais esquemas. Nota-se também que o esquema pode ser composto por uma ou mais tabelas. Observa-se ainda, através das Figuras 11e 12, que o metamodeloIMMapresenta elementos relacionados ao projeto físico deBD, por exemplo, os elementos Database Instance, Temporary Table, Materialized View e View. Além desses, o metamodelo traz os conceitos que estão fora do escopo do projeto lógico tais como: controle de acesso, permissões em objetos e índices.

Figura 12 –IMM: Definição Database Instance e Schema

Fonte:OMG(2005).

3.2

Notações Gráficas

Para efetuar a comparação das notações gráficas dos trabalhos relacionados, foram criados critérios com base nos conceitos do modelo relacional. Foi realizada, então, uma avaliação para verificar se a notação gráfica oferece suporte aos critérios definidos. Para tanto, cada critério foi analisado e um símbolo foi utilizado para indicar se a notação dá suporte ao conceito, em caso afirmativo, foi utilizado o símbolo (O) e, caso contrário, o símbolo (X). Os critérios definidos com base nos conceitos da secção §2.1são:

1. Relação - identifica se existe uma representação gráfica na notação para exibir a relação; 2. Atributo - verifica se a notação exibe os atributos pertencentes a uma determinada relação; 3. Domínio - analisa existe uma representação para identificar no modelo os domínios

defini-dos pelo usuário;

4. Restrição de Domínio - checa se são exibidas as restrições de domínio dos atributos; 5. Restrição NOT NULL - avalia se existe a possibilidade de identificar visualmente se um

exibidas;

7. Chave Primária (PK) - investiga se existem elementos que representam a definição de uma chave primária;

8. Chave Estrangeira (FK) - analisa a notação para identificar se há elementos que repre-sentam uma chave estrangeira;

9. Chave Única - avalia se existem elementos que representam a definição de uma chave única;

10. Operação e violações de restrição - checa se as restrições de violação em caso de atuali-zação ou exclusão são representadas;

11. Restrições semânticas - verifica se existe representação gráfica para as restrições do tipo Assertione Trigger;

12. Clareza no relacionamento entre relações - analisa se é possível identificar os atributos que fazem parte do relacionamento e qual a dependência entre as relações.

3.2.1 Notação deElmasri e Navathe(2015)

Em sua obra,Elmasri e Navathe(2015) traz uma notação gráfica em forma de diagrama de um esquema deBDrelacional que, embora não definida formalmente, essa notação é utilizada para fins acadêmicos. Na figura13, é apresentado um esquema deBDrelacional EMPRESA que exemplifica a notação. Observa-se que as relações são identificadas através do nome em negrito e caixa alta, seguido de um retângulo disposto na horizontal e preenchido com os atributos. Nota-se que, os atributos que compõem as chaves primárias são sublinhados. Ainda pode-se observar que é desenhado um arco direcionado do atributo da chave estrangeira para o atributo que representa a chave primária da relação, que a chave estrangeira referencia. Por exemplo, na relação DEPARTMENT, o atributo Mgr_ssn referencia o atributo Ssn da relação EMPLOYEE.

A partir da figura13, é possível observar que o diagrama apresentado porElmasri e Navathe(2015) não expressa todos os conceitos do modelo relacional. De acordo como o esquema exibido, foram identificados apenas os conceitos de relação, domínio, chave primária e chave estrangeria. Na ligação entre as relações, é possível identificar de forma clara a dependência entre as relações e os atributos que fazem parte da chave estrangeria, bem como qual atributo da chave primária está sendo referenciado. Apesar disso, não foi encontrado um exemplo utilizando essa notação onde a chave estrangeira referencia uma relação que contenha uma chave primária com mais de um atributo. Na tabela2são apresentados os conceitos suportados pela notação.

Figura 13 – Exemplificação da notação de Elsmari&Navathe

Fonte:Elmasri e Navathe(2015).

Tabela 2 – Tabela dos conceitos suportados pela notação Elsmari&Navathe(2011).

Conceito Suporta?

Relação O

Atributo O

Domínio X

Restrição de Domínio X

Restrição NOT NULL X

Check X

Chave Primária (PK) O

Chave Estrangeira (FK) O

Chave Única X

Operação e violações de restrição X

Restrição semânticas X

Clareza no relacionamento entre relações O

3.2.2 Notação de Silberschatz

A notação apresentada porSilberschatz, Korth e Sudarshan (2011), assim com a de

Elmasri e Navathe(2015), não possui uma definição formal de seus elementos e sua principal utilização se dá em meio acadêmico. Na figura14, apresenta-se um diagrama de esquema de uma organização universitária utilizando a notação de Silberchatz. Nota-se, a partir da figura, que ambas as notações, a de Silberschatz e a de Elsmari&Navathe, se valem de linhas e setas para indicar os relacionamentos entre as Relações. Da mesma forma, os atributos que fazem

em que o atributo ID é a chave primária. Pode-se observar que, a seta aponta dos atributos da chave estrangeira da relação em direção aos atributos da chave primária da relação referenciada. Outra característica da notação de Silberschatz é que essa apresenta as Relações como retângulos com dois compartimentos: um superior, que possui o nome da relação, e um inferior no qual são elencados todos os atributos da relação.

Figura 14 – Exemplificação da notação de Silberschatz

Fonte:Silberschatz, Korth e Sudarshan(2011).

A partir da imagem do esquema relacional, observa-se que o diagrama apresentado por

Silberschatz, Korth e Sudarshan(2011) não explora todos os conceitos do modelo relacional. Da mesma forma queElmasri e Navathe(2015), a notação contempla apenas os conceitos básicos tais como: relação, domínio, chave primária e chave estrangeria. Na ligação entre as relações, observa-se que uma chave estrangeira pode gerar mais de um arco entre as relações para referenciar a todos os atributos da chave primária. Isso pode ser observado através da chave estrangeira da relação takesreferenciando a relação section. Na tabela3, estão detalhados os conceitos suportados pela notação, que são os mesmos apresentados na tabela2, referentes à notação de Elsmari&Navathe .

Tabela 3 – Tabela dos conceitos suportados pela notação de Silberschatz Conceito Suporta? Relação O Atributo O Domínio X Restrição de Domínio X

Restrição NOT NULL X

Check X

Chave Primária (PK) O

Chave Estrangeira (FK) O

Chave Única X

Operação e violações de restrição X

Restrição semânticas X

Clareza no relacionamento entre relações O

3.2.3 Information Engineering - IE

A técnica Information Engineering (IE) (HAY,1999a) foi inicialmente desenvolvida pelo australiano Clive Finkelstein nos anos 1970. A partir de uma colaboração com James Martin, ele conseguiu publicar seu trabalho tanto nos Estados Unidos quanto na Europa. Entretanto, Martin acabou seguindo com a pesquisa, tornando-se o principal nome associado à notação (HAY,1999b). Devido à essa origem dupla, é comum encontrar pequenas divergências entre os padrões dos dois autores. SegundoHarrington(1998), os diagramas IE trocam simplicidade por mais informação através de símbolos utilizados nas conexões entre as relações.

Na figura15, é apresentado um exemplo de modelagem utilizando a notação IE. Observa-se através do elementos do diagrama, que a notação é pensada mais para um modelagem conceitual do que lógica. As linhas indicam relacionamentos entre as relações, e seus conectores têm o papel de indicar cardinalidade e a obrigatoriedade (ou não) dos relacionamentos. Esse tipo de notação é comumente referido como pé de galinha. Neste diagrama, o símbolo * é utilizado para identificar os atributos que fazem parte da chave primária da relação.

A partir da análise da figura15, percebe-se que o diagrama utilizando a notação IE não expressa todos os conceitos do modelo relacional. De acordo como o esquema exibido, foram identificados apenas os conceitos de relação, atributo e chave primária. Apesar de existir ligação ente as relações, não é exiba de forma clara a dependência entre as relações (como pode ser observado no relacionamento entre as relações Producer e Item), nem qual atributo da chave primária está sendo referenciado. Na tabela 4, são apresentados os conceitos suportados nos diagramas que utilizam notação IE.