Larissa Cristina Moraes Qualificação de mestrado Instituto...

Representação de variabilidade estrutural de dadospor meio de famílias de esquemas de banco de dados

Larissa Cristina Moraes

Qualificação de mestrado

Instituto de Matemática e Estatística

da

Universidade de São Paulo

Programa: Ciência da ComputaçãoOrientadora: Profa. Dra. Kelly Rosa Braghetto

Durante o desenvolvimento deste trabalho a autora recebeu auxílio financeiro da FAPESPProcesso: 2014/18216-2

São Paulo, junho de 2015

Resumo

MORAES, L. C. Representação de variabilidade estrutural de dados por meio defamílias de esquemas de banco de dados. Dissertação (Mestrado) - Instituto de Matemáticae Estatística, Universidade de São Paulo, São Paulo, 2015.

Esquemas conceituais de banco de dados podem ser usados para criar representaçõespadronizadas dos dados de um determinado domínio de aplicação. Apesar das semelhanças queexistem entre os requisitos de dados de organizações de um mesmo domínio, certa variabilidadepode ser necessária para acomodar as necessidades específicas de cada organização. As técnicastradicionais de modelagem conceitual de banco de dados (como o Modelo Entidade Relacionamento- MER - e a Linguagem Unificada de Modelagem – UML) não nos permite expressar essavariabilidade de dados. Para abordar esse problema, este projeto de mestrado propõe uma novatécnica de modelagem – os Diagramas de Características de Banco de Dados (DBFDs, do inglêsDatabase Feature Diagrams) – projetada para apoiar a criação de famílias de esquemas conceituaisde banco de dados. Uma família de esquemas conceituais de banco de dados compreende todas aspossíveis variações de esquemas conceituais de banco de dados para um determinado domíniode aplicação. Os DBFDs são uma extensão do conceito de Diagrama de Características usadona Engenharia de Linhas de Produtos de Software. Por meio dos DBFDs, será possível geraresquemas conceituais de banco de dados customizados para atender às necessidades específicas deusuários ou organizações ao mesmo tempo que se garante uma padronização dos requisitos dedados do domínio de aplicação. Além disso, os DBFDs tornarão a evolução de bancos de dadosexistentes mais fácil, já que cada modificação feita no DBFD é definida de forma modular. Apartir de um modelo conceitual customizado, o banco de dados (físico) correspondente será criadoou evoluído automaticamente por meio de ferramentas computacionais que serão desenvolvidas.Outra proposta deste projeto é validar a técnica de modelagem que será desenvolvida por meio deum estudo de caso no domínio de dados experimentais de neurociência. Para isso, será modeladauma família de esquemas conceituais para esse domínio, bem como será desenvolvida uma notaçãoque permitirá que neurocientistas estendam a família de forma facilitada. O estudo de caso trarácontribuições específicas para o domínio de neurociência, pois permitirá criar representaçõespadronizadas para dados experimentais com alguma variabilidade estrutural.

Palavras-chave: variabilidade, diagrama de características, banco de dados personalizado, expe-rimentos de neurociência.

iii

Sumário

Lista de Figuras vii

1 Introdução 11.1 Contextualização do Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Objetivos Gerais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Contribuições Esperadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.4 Organização do Texto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Fundamentos 52.1 Modelagem de Banco de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.1 Modelagem Conceitual com o Modelo Entidade-Relacionamento (MER) . . . 62.1.2 Modelagem Conceitual Baseada em Modelo de Objetos . . . . . . . . . . . . . 92.1.3 Modelagem Física . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2 Linhas de Produtos de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.2.1 Abordagens Clássicas de Engenharia de Domínio . . . . . . . . . . . . . . . . 12

2.3 Considerações sobre os Conceitos Apresentados . . . . . . . . . . . . . . . . . . . . . 14

3 Trabalhos Relacionados 153.1 Modelagem Conceitual de Banco de Dados . . . . . . . . . . . . . . . . . . . . . . . . 153.2 Uso de Linhas de Produtos de Software em Banco de Dados . . . . . . . . . . . . . . 16

4 Proposta 174.1 Método . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.1.1 Aplicação Específica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184.2 Validação e Avaliação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

5 Resultados Preliminares 215.1 Diagramas de Características de Banco de Dados . . . . . . . . . . . . . . . . . . . . 21

5.1.1 Relações nos DBFDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225.1.2 Anotações nos DBFDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

5.2 Projetando uma Família de Esquemas Conceituais de Banco de Dados . . . . . . . . 24

6 Estudo de Caso: Dados Experimentais de Neurociência 256.1 Apresentação do Domínio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256.2 Representação e Armazenamento de Dados em Neurociência . . . . . . . . . . . . . . 266.3 Aplicando os DBFDs na Modelagem de Dados Experimentais de Neurociência . . . . 27

6.3.1 Uma Breve Descrição dos Requisitos de Dados . . . . . . . . . . . . . . . . . 276.3.2 Módulos de Dados, DBFD e Anotações . . . . . . . . . . . . . . . . . . . . . 28

7 Planejamento 337.1 Atividades e Cronograma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337.2 Comentários Adicionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

v

vi SUMÁRIO

A O centro de Pesquisa, Inovação e Difusão em Neuromatemática 35

Referências Bibliográficas 37

Lista de Figuras

2.1 Notação usada em diagramas ER. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2 Diagrama ER para uma Empresa. Extraído de [EN10] . . . . . . . . . . . . . . . . . 72.3 Diagrama EER com especialização. Extraído de [EN10] . . . . . . . . . . . . . . . . 82.4 Diagrama EER com categorização. Extraído de [EN10] . . . . . . . . . . . . . . . . . 92.5 Diagrama de Classes UML para uma Empresa. Extraído de [EN10] . . . . . . . . . . 102.6 Diagrama de características para sistema de telefones móveis. Adaptado de [BSRC]. 13

5.1 Diagrama de Características para um sistema de compras online. Adaptado de [Seg]. 22

6.1 Módulos de dados com informações básicas sobre experimentos. . . . . . . . . . . . . 286.2 Módulos de dados relacionados a grupos de sujeitos dos experimentos. . . . . . . . . 286.3 Módulos de dados relacionados ao protocolo experimental. . . . . . . . . . . . . . . . 296.4 Módulos de dados da estrutura organizacional dos projetos de pesquisa. . . . . . . . 296.5 Diagrama de Características de Banco de Dados para o estudo de caso. . . . . . . . . 296.6 Um esquema conceitual de banco de dados derivado do DBFD da Figura 6.5. . . . . 31

vii

viii LISTA DE FIGURAS

Capítulo 1

Introdução

1.1 Contextualização do Problema

Esquemas conceituais de banco de dados podem ser usados para criar representações padroni-zadas dos dados de um domínio de aplicação. Apesar das semelhanças que existem nos requisitosde dados de organizações de um mesmo domínio de aplicação, certa variabilidade pode ser ne-cessária para acomodar as necessidades específicas de cada organização. A criação de esquemasconceituais de banco de dados que são flexíveis o bastante para prover representações padronizadaspara dados com algum nível de variabilidade em suas estruturas é um desafio que ainda dificulta ocompartilhamento de dados entre organizações do mesmo domínio de aplicação.

Um exemplo recorrente desse fato acontece em projetos de pesquisa que coletam grandes volu-mes de dados experimentais. Um projeto de pesquisa desse tipo geralmente tem vários laboratóriosde pesquisa participantes, cada um deles conduzindo tipos específicos de experimentos e armaze-nando seus dados experimentais em seu próprio banco de dados local. Nesse cenário heterogêneo,o projeto de pesquisa deve garantir que: (i) todas as informações essenciais sobre os experimen-tos sejam coletadas por todos os laboratórios participantes; e, (ii) todos os dados coletados peloslaboratórios participantes estejam organizados em uma estrutura padronizada, para permitir o com-partilhamento de dados entre os membros do projeto. Em outras palavras, é desejável que todos osbancos de dados locais tenham uma parte comum em seus esquemas, e que a variabilidade existenteem seus esquemas seja de alguma forma controlada por um modelo de dados padrão especificadopara o projeto.

Note que um cenário similar pode ocorrer em uma companhia matriz e suas filiais. Dentrodessa hierarquia, todas as empresas vendem o mesmo produto ou serviço e, portanto, devem conterestruturas comuns nos seus bancos de dados locais de forma a facilitar o compartilhamento de dadosentre elas. Essa necessidade se torna essencial caso haja um banco de dados centralizado para todasas empresas, por exemplo. Ao mesmo tempo, cada empresa terá suas particularidades e, portanto,alguns tipos de dados variarão de empresa para empresa. É importante que o armazenamentodesses dados no banco de dados aconteça de forma padronizada para facilitar o seu entendimentopor outras empresas.

Um cenário em particular onde a variabilidade estrutural de dados pode ser vista com clarezaé o domínio de neurociência. Existem diferentes tipos de experimentos realizados em neurociência,como, por exemplo, os comportamentais, cognitivos, eletrofisiológicos e de neuroimagem. Todasas definições sobre um experimento, incluindo definições sobre os objetivos, a descrição dos gruposde sujeitos que serão testados, as condições experimentais às quais os grupos serão submetidose os tipos de coletas de dados que serão realizados, são chamadas pelos cientistas de protocoloexperimental. Essas informações são importantes para que um cientista possa fazer uma análisecorreta dos dados coletados a partir dos experimentos.

Além disso, há outras informações “ortogonais” à realização do experimento que também sãomuito importantes para definir a qualidade dos dados coletados. Como por exemplo, informaçõessobre o laboratório onde os dados foram coletados, sobre o cientista responsável pelo experimento,

1

2 CAPÍTULO 1. INTRODUÇÃO

a data de realização do experimento e até mesmo publicações ou outros resultados decorrentes doestudo dos dados coletados.

No contexto de neurociência, tanto as informações do protocolo experimental quanto as informa-ções ortogonais à realização dos experimentos variam de laboratório para laboratório de pesquisa.Portanto, para que os laboratórios consigam trocar informações a respeito de seus experimentos etambém possam compartilhar seus dados com a comunidade científica é necessário que haja umaestrutura padronizada para a representação e o armazenamento dos dados. Entretanto, ainda nãoexistem propostas de representações padronizadas que acomodem de forma satisfatória toda a va-riabilidade que existe nas estruturas dos dados de experimentos de neurociência.

Uma das causas da dificuldade de se criar representações padronizadas para domínios de apli-cação como os citados acima é o fato de que as técnicas tradicionais de modelagem conceitual debanco de dados (como o Modelo Entidade Relacionamento - MER - e a Linguagem Unificada deModelagem - UML) não nos permitem representar em um mesmo modelo diferentes variações deesquema para um dado domínio de aplicação. Cada possível variação do esquema deve ser definidaem um modelo separado. Isso torna difícil manter e evoluir os esquemas conceituais de banco dedados do domínio, principalmente considerando suas estruturas comuns (ou frequentes), que devemser replicadas em todos os modelos.

1.2 Objetivos Gerais

Neste trabalho de mestrado, abordaremos o problema da representação da variabilidade estru-tural que existe em alguns domínios de aplicação por meio da criação de famílias de esquemasconceituais de banco de dados. Uma família de esquemas conceituais de banco de dados deverácompreender todas as possíveis variações de esquemas conceituais de banco de dados para um de-terminado domínio de aplicação. O objetivo principal do trabalho é desenvolver uma nova técnicade modelagem – os Diagramas de Características de Banco de Dados (DBFDs, do inglês DatabaseFeature Diagrams) – para apoiar a criação dessas famílias de esquemas.

A ideia de se criar uma família de esquemas de dados se baseia em um paradigma da Engenhariade Software chamado de Engenharia de Linhas de Produtos de Software (LPSs), também conhecidopor famílias de aplicações. Uma LPS agrupa um conjunto de aplicações que são construídas sobreuma plataforma tecnológica comum, mas que se diferem entre si por funcionalidades que podemvariar de um produto para o outro. Existem diversos modelos teóricos, arcabouços e ferramentascriados para amparar o projeto e a criação de LPSs. Neste trabalho de mestrado, essas ferramentasserão estudadas e adaptadas para o apoio à criação de famílias de esquemas conceituais de dados ede seus respectivos esquemas físicos.

Os DBFDs são uma extensão do conceito de Diagrama de Características usado nas LPSs. Emum DBFD, os requisitos de dados do domínio serão modelados como relações entre módulos dedados. Cada módulo de dados é um artefato reutilizável que modela objetos de dados que estãofisicamente ou semanticamente relacionados. As relações (e suas anotações associadas) definemcomo os módulos podem ser conceitualmente combinados de forma a satisfazer os requisitos dedados do domínio modelado.

Um DBFD deve ter módulos de dados base, que modelam requisitos de dados que são comunspara todos os usuários do domínio de aplicação, e módulos de dados opcionais ou alternativos, querepresentam o que pode ser combinado de diferentes maneiras para criar esquemas conceituais per-sonalizados. Assim, módulos opcionais podem ser selecionados para serem adicionados aos módulosbase, criando uma instância específica de esquema conceitual a partir do DBFD, para representaros requisitos de dados específicos de um usuário ou organização. Uma família de esquemas de dadospoderá ser facilmente estendida toda vez que um novo requisito de dado apareça no domínio deaplicação, bastando adicionar novos módulos no DBFD correspondente e conectá-los aos módulospreexistentes por meio de novas relações.

Portanto, por meio dos DBFDs, será possível gerar esquemas conceituais de banco de dadoscustomizados para atender às necessidades específicas de usuários ou organizações ao mesmo tempo

1.3. CONTRIBUIÇÕES ESPERADAS 3

que se garantirá uma padronização dos requisitos de dados do domínio de aplicação. Todos osesquemas gerados de um mesmo DBFD serão membros da mesma família de esquemas, que temuma estrutura base comum. E todas as variações que podem aparecer nos esquemas de umafamília serão totalmente controladas pelo DBFD correspondente. Além disso, os DBFDs tornarão aevolução de bancos de dados existentes mais fácil, já que cada modificação feita no DBFD é definidade forma modular.

A partir dos esquemas conceituais customizados, será possível gerar automaticamente os mo-delos lógicos e físicos correspondentes por meio de ferramentas computacionais. Para isso, serádesenvolvida uma ferramenta de software que terá como funcionalidades principais a criação e edi-ção de um DBFD e a edição dos esquemas conceituais presentes nos módulos de dados do DBFD.Quando finalizada a edição do DBFD, será possível selecionar os módulos opcionais, além dos mó-dulos base que são obrigatórios, para criar os modelos conceituais customizados e a partir dessesgerar os modelos lógicos e físicos.

A viabilidade e os benefícios do uso da técnica de modelagem e das ferramentas computacionaisdesenvolvidas neste trabalho de mestrado serão verificados por meio de seu uso em um domínio deaplicação real: o gerenciamento de dados experimentais de neurociência em um grande projeto depesquisa.

1.3 Contribuições Esperadas

Espera-se para este projeto de mestrado dois tipos de contribuições: contribuições de propósitogeral e contribuições específicas para o domínio de neurociência. Como contribuições de propósitogeral, é possível destacar:

1. o desenvolvimento de uma nova técnica de modelagem conceitual para criar famílias de es-quemas conceituais de banco de dados para representar variabilidade de dados;

2. a criação de ferramentas computacionais de apoio à criação e evolução automática de bancos dedados (físicos) a partir de esquemas conceituais derivados das famílias de esquemas modeladascom a nova técnica.

Por meio de um estudo de caso no domínio de dados experimentais de neurociência, pretende-se mostrar como a nova técnica de modelagem e as ferramentas computacionais desenvolvidas noprojeto podem ser usadas para criar representações padronizadas para dados com alguma variabi-lidade estrutural. Esse estudo de caso será usado também para avaliar a facilidade de evolução dosmodelos criados por meio da nova técnica. Assim, pretende-se como contribuições específicas parao domínio da neurociência:

1. a modelagem de uma família de esquemas conceituais para representar dados de experimentosde neurociência;

2. o desenvolvimento de uma notação que possibilitará que a família seja diretamente estendidapor neurocientistas (ou seja, usuários que não necessariamente são especialistas em modelagemde banco de dados).

Há ainda outras contribuições decorrentes das listadas acima, como: a criação de novos padrõespara reportar dados de experimentos em neurociência e o incentivo de seu uso pela comunidadecientífica; a facilitação do compartilhamento de dados entre cientistas que estão geograficamentedistribuídos, mas que cooperam no contexto de um mesmo projeto de pesquisa; a viabilização doreúso de dados e o apoio à reprodutibilidade de experimentos.

1.4 Organização do Texto

No Capítulo 2, serão apresentados os principais conceitos utilizados para a criação de famílias deesquemas conceituais de bancos de dados: modelagem de banco de dados, com ênfase em modelagemconceitual, e o paradigma de linhas de produtos de software.

4 CAPÍTULO 1. INTRODUÇÃO

O Capítulo 3 contém trabalhos relacionados a esta proposta de mestrado, sendo dividido emduas partes. A primeira apresenta abordagens que tratam a modelagem conceitual de banco dedados de forma flexível ou evolutiva. A segunda trata de trabalhos que abordam o uso de linhas deprodutos de software na área de banco de dados.

No Capítulo 4 são apresentados mais detalhes sobre a proposta para este trabalho de mestrado,com descrição do método e das formas de validação e avaliação que serão utilizados.

Os resultados preliminares obtidos neste trabalho de mestrado, como a nova técnica de mode-lagem proposta e um método para a sua aplicação, são detalhados no capítulo 5. O estudo de casopara o domínio de experimentos de neurociência que está sendo utilizado para validar o métodoproposto é apresentado no Capítulo 6.

O Capítulo 7 trata do planejamento para a continuação do mestrado, contendo as próximasatividades a serem desenvolvidas com um cronograma de execução das mesmas.

Capítulo 2

Fundamentos

O projeto de mestrado descrito neste texto se propõe a criar famílias de esquemas conceituais debanco de dados. A criação desses esquemas envolve métodos e técnicas para modelagem de bancosde dados, que são descritos na Seção 2.1.

O conceito de famílias de esquemas de dados abordado neste trabalho se baseia no de famíliasde artefatos de software, um tópico explorado pelo paradigma de Linhas de Produtos de Software,que será introduzido na Seção 2.2.

2.1 Modelagem de Banco de Dados

Um banco de dados é uma coleção de dados relacionados que podem ser armazenados e quepossuem um significado implícito. Os dados podem ser armazenados fisicamente de diferentesformas, como, por exemplo, em papel ou em um disco rígido, por meio do uso de um computador.O ciclo de vida de um banco de dados consiste nas fases de definição, construção, manipulação ecompartilhamento dos dados.

Uma etapa inicial importante da fase de definição de um banco de dados é a análise de re-quisitos de dados, onde serão especificadas as características dos dados a serem armazenados e asnecessidades dos usuários com relação a esses dados. Os objetivos principais dessa fase são: levan-tar os requisitos de dados em termos de elementos de dados básicos e generalizados; descrever ainformação e os relacionamentos dos elementos de dados para modelar os requisitos; determinar asoperações que serão executadas sobre cada elemento de dados; definir os requisitos relacionados aintegridade, segurança e controle de acesso, bem como as restrições que devem ser impostas sobreos dados no banco. Todos os requisitos de dados devem ser documentados, facilitando a interaçãoentre os usuários e o banco de dados.

A partir da análise de requisitos, começa a fase de definição do banco de dados, que consistena modelagem conceitual do BD, para a posterior modelagem física do mesmo. A modelagem sebaseia em modelos de dados, que são conjuntos de conceitos que podem ser usados para criar umesquema que descreve a estrutura de um banco. Essa fase de definição é muito importante paraque a construção do banco seja eficaz e eficiente [TLNJ11].

O modelo conceitual de dados descreve a estrutura do banco de dados em alto nível, em umarepresentação que mesmo usuários não especialistas compreendem bem. Os modelos físicos de dadosdescrevem os detalhes sobre como os dados são armazenados fisicamente no computator. Existemodelos que estão entre os modelos conceituais e os físicos – os modelos de dados representativos(também chamados de modelos de dados de implementação). Esses modelos ocultam alguns dosdetalhes sobre o armazenamento físico, mas podem ser implementados diretamente em um sistemade computador [EN10].

Existem diferentes modelos de dados para a criação do modelo conceitual, entre eles, o Mo-delo Entidade-Relacionamento, o Modelo Entidade-Relacionamento Estendido e a Linguagem deModelagem Universal.

5

6 CAPÍTULO 2. FUNDAMENTOS

2.1.1 Modelagem Conceitual com o Modelo Entidade-Relacionamento (MER)

O Modelo Entidade Relacionamento (MER) é um modelo popular para modelagem conceitualde dados. Esse modelo e suas variações, como o Modelo Entidade-Relacionamento Estendido, sãofrequentemente usados para o projeto conceitual de aplicações de banco de dados. As extensões doMER são geralmente usadas na modelagem conceitual de bancos de dados mais complexos, comoos bancos de dados científicos.

O MER se baseia em três conceitos básicos: entidades, atributos e relacionamentos. Umaentidade representa um elemento do mundo real (que pode ou não ter uma existência física), comoum funcionário ou uma disciplina. Um atributo corresponde a alguma propriedade de interesseda entidade, como o nome do funcionário ou a siga da disciplina. Um atributo pode ser: simplesou atômico, quando não pode ser dividido, como nome; composto, que é dividido em várias partes,como endereço, que é dividido em rua, número e cep; de valor único, que tem um só valor parauma determinada entidade, como idade; multivalorado, que pode assumir vários valores para umadeterminada entidade, como telefone; e derivado, que é um atributo que pode ser determinado apartir de outros atributos, como idade, que pode ser calculada a partir da data de nascimento eda data de hoje.

Um banco de dados pode conter grupos de entidades que são similares, ou seja, compartilham dosmesmos atributos. Mas cada entidade tem um valor para cada atributo. Esse grupo de entidadessimilares é chamado de tipo de entidade. Cada tipo de entidade é descrito por seu nome e seusatributos. Por exemplo, Empregado é um tipo de entidade que contém os atributos cpf, nome,idade e salário.

Todo tipo de entidade tem um ou mais atributos chave, cujos valores são distintos para cadaentidade do conjunto de entidades. Portanto, os valores desses atributos podem identificar umaúnica entidade. Para o tipo de entidade Empregado, podemos usar cpf como atributo chave. Ostipos de entidade que não tem atributos chave são chamados de tipos de entidade fraca. Sua chaveserá determinada por um tipo de relacionamento com uma entidade forte.

Um relacionamento se dá entre duas ou mais entidades e representa uma associação entre estas,como o relacionamento trabalha-em entre um funcionário e um projeto. Um conjunto deassociações ou relacionamentos entre entidades é definido como um tipo de relacionamento entretipos de entidade. Todo tipo de relacionamento contém um grau, que indica o número de tipos deentidade que participam desse relacionamento. Os tipos de relacionamento podem conter atributos,por exemplo, o tipo de relacionamento trabalha-em pode ter como atributo horas para indicarquantas horas cada empregado trabalha no departamento.

Os tipos de relacionamento de grau dois, ou binários, apresentam dois tipos de restrições: ade cardinalidade e a de participação. A cardinalidade de um relacionamento especifica o númeromáximo de instâncias do relacionamento em que uma entidade pode participar. Por exemplo, otipo de relacionamento trabalha-em entre empregado e departamento tem cardinalidade N:1, oque significa que cada empregado pode trabalhar em somente um departamento, enquanto que emcada departamento podem trabalhar inúmeros empregados. As cardinalidades possíveis são: 1:1,1:N, N:1 e M:N.

A restrição de participação de um relacionamento especifica o número mínimo de instânciasdo relacionamento em que cada entidade deve participar. Existem dois tipos de participação, atotal e a parcial. Se considerarmos que todo empregado deve trabalhar em um departamento,então a participação de empregado no tipo de relacionamento trabalha-em é total. Já no tipo derelacionamento gerencia, podemos dizer que a participação de empregado é parcial, pois nem todoempregado gerencia um departamento.

Os diagramas ER são utilizados como uma notação diagramática associada ao MER. A Fi-gura 2.1 contém um resumo das notações para um diagrama ER, e a Figura 2.2 apresenta umexemplo de diagrama ER para o esquema de uma empresa.

2.1. MODELAGEM DE BANCO DE DADOS 7

Figura 2.1: Notação usada em diagramas ER.

Figura 2.2: Diagrama ER para uma Empresa. Extraído de [EN10]


O Modelo Entidade-Relacionamento Estendido (EER, do inglês Enhanced Entity Relationship)introduz construtores adicionais que possibilitam a representação de conceitos como o de especiali-zação, generalização e categorização.

Especialização é o processo de definir um conjunto de subclasses de um tipo de entidade; esse tipode entidade é chamado de superclasse da especialização. Por exemplo, Secretária, Engenheiro eMédico são subclasses de Empregado. Generalização é o processo reverso da especialização, ou seja,as características comuns de diferentes tipos de entidades são identificadas e generalizadas em umaúnica superclasse. A Figura 2.3 mostra exemplos de especialização em um diagrama EER para umaempresa.

Existem dois tipos de restrições aplicada à especialização: de disjunção e de completude. Arestrição de disjunção especifica que as subclasses da especialização devem ser disjuntas, ou seja, umaentidade pode ser membro de no máximo uma das subclasses da especialização. Uma especializaçãodisjunta é representada com um d dentro do círculo. Se as subclasses não forem disjuntas, entãoelas são sobrepostas e a especialização sobreposta será representada com um o dentro do círculo. Arestrição de completude pode ser total ou parcial. Uma especialização total indica que toda entidadeda superclasse deve ser membro de pelo menos uma das subclasses e é representada pela linha duplaque liga a superclasse ao círculo. Quando a especialização é parcial ela é representada com umalinha única e permite que uma entidade não pertença a nenhuma das subclasses. Geralmente, asuperclasse identificada na generalização é total, pois ela é derivada das subclasses e por isso contémapenas entidades que estão nas subclasses.

Figura 2.3: Diagrama EER com especialização. Extraído de [EN10]

Na categorização, uma subclasse, chamada categoria, vai representar uma coleção de objetosque é um subconjunto da união de tipos de entidades distintos. Por exemplo, em um banco dedados para registro de veículos, um dono de um veículo pode ser uma pessoa, um banco ou umaempresa. Nesse caso, uma classe (coleção de entidades) será criada para incluir todos os três tiposde entidades que desempenham o papel de dono do veículo. A categoria Dono que é uma subclassede união do conjunto de três tipos de entidades (Empresa, Banco e Pessoa) vai ser criada paraatender essa necessidade. As superclasses Empresa, Banco e Pessoa são conectadas ao círculo como símbolo U, que representa a operação de união de conjuntos.

Uma categoria pode ser total ou parcial. Uma categoria total contém a união de todas asentidades em suas superclasses, enquanto que uma categoria parcial pode conter um subconjuntoda união. A Figura 2.4 mostra dois exemplos de categorização em um diagrama EER.

2.1. MODELAGEM DE BANCO DE DADOS 9

Figura 2.4: Diagrama EER com categorização. Extraído de [EN10]

2.1.2 Modelagem Conceitual Baseada em Modelo de Objetos

Existem metodologias de modelagem de objetos, como a Linguagem de Modelagem Universal(UML, do inglês Unified Modeling Language), que são populares em projeto tanto de banco dedados quanto de software. A UML utiliza vários tipos de diagramas para ir além do projeto debanco de dados e especificar detalhadamente o projeto de módulos de software e suas interações.Na UML, um dos tipos de diagramas mais utilizados é o diagrama de classes, como o da Figura 2.5,que representa um esquema de uma empresa de forma similar à Figura 2.2. Nos diagramas declasse da UML, uma classe é similar a um tipo de entidade do ER, enquanto que as associaçõescorrespondem aos tipos de relacionamento do ER.


Figura 2.5: Diagrama de Classes UML para uma Empresa. Extraído de [EN10]

2.1.3 Modelagem Física

Para que um esquema conceitual possa ser usado para criar um banco de dados real, é precisoque ele seja mapeado em um esquema de modelo físico ou de implementação que, por sua vez, serámapeado em comandos em uma linguagem de definição de dados (DDL - data definition language),como a linguagem SQL (Structured Query Language) [TLNJ11].

Os modelos mais usados para a modelagem física dos dados são modelos de implementação: oModelo Relacional e o Modelo de Dados de Objetos. O Modelo Relacional representa o banco dedados como uma coleção de relações, onde uma relação é vista como uma tabela de valores, emque cada linha na tabela representa uma coleção de dados relacionados (podendo representar tantouma entidade quanto um relacionamento).

Já o Modelo de Dados de Objetos utiliza muitos dos conceitos que foram desenvolvidos original-mente nas linguagens de programação orientadas a objeto. Bancos de dados relacionais que incor-poram algumas características de bancos de dados de objetos são chamados de objeto-relacionais.Algumas características do Modelo de Dados de Objeto que são comumente incluídas nesses bancossão: construtores de tipos para especificar objetos complexos; um mecanismo para especificar aidentidade de objetos; mecanismos de herança; mecanismos para o encapsulamento de operações.

O mapeamento de um modelo conceitual para um modelo de implementação pode ser feito deforma automática seguindo algoritmos de mapeamento. Por exemplo, existe um algoritmo de setepassos para o mapeamento de modelos ER para modelos relacionais [EN10]. Os passos a seremseguidos, descritos de maneira simplificada, são:

1. Para cada conjunto de entidades E, deve ser criada uma tabela com todos os atributos de E.Deve ser escolhida uma chave candidata para ser a chave primária da tabela.

2. Para cada relacionamento binário 1:1 entre os conjuntos de entidades E1 e E2, deve-se escolheruma das tabelas, por exemplo E2, e incluir como chave estrangeira em E2 a chave primária daoutra tabela (E1). Os atributos do relacionamento devem ser incluídos na tabela com chaveestrangeira.

3. Para cada relacionamento binário 1:N entre os conjuntos de entidades E1 e E2, deve ser esco-lhido o conjunto de entidades do lado N, por exemplo E2, para incluir como chave estrangeira

2.2. LINHAS DE PRODUTOS DE SOFTWARE 11

da tabela E2 a chave primária da tabela E1. Os atributos do relacionamento também sãoincluídos na tabela com chave estrangeira.

4. Para cada relacionamento binário N:N entre os conjuntos de entidades E1 e E2, é necessáriocriar uma nova tabela auxiliar tab-aux para representar o relacionamento e incluir como chavesestrangeiras na tabela tab-aux as chaves primárias de E1 e E2. Estes dois atributos comporãoa chave primária de tab-aux. Os atributos do relacionamento devem ser incluídos na tabelatab-aux.

5. Para relacionamento de grau maior que 2, deve-se criar uma nova tabela auxiliar tab-aux pararepresentar o relacionamento e incluir como chaves estrangeiras na tabela tab-aux as chavesprimárias das tabelas que participam do relacionamento.

6. Para cada conjunto de entidades fracas F será criada uma tabela T com todos os atributosde F e será incluído como chave estrangeira de T a chave primária da tabela correspondenteao conjunto de entidades fortes R. A chave primária de T será a chave parcial de F mais achave primária de R.

7. Para cada atributo multivalorado A de um conjunto de entidades E1, deve-se criar uma tabelaT com o atributo A e incluir como chave estrangeira em T a chave primária de E1. A chaveprimária de T será composta do atributo A mais a chave primária de E1.

A Tabela 2.1 resume os mapeamentos que devem ser feitos.

Tabela 2.1: Resumo do mapeamento do modelo ER para o modelo relacional.

Modelo ER Modelo ConceitualTipo de entidade Relação de entidadeTipo de relacionamento 1:1 ou 1:N Chave estrangeira (ou relação de relacionamento)Tipo de relacionamento M:N Relação de relacionamento e duas chaves estrangeirasTipo de relacionamento n-ário Relação de relacionamento e n chaves estrangeirasAtributo simples AtributoAtributo composto Conjunto de atributos componentes simplesAtributo multivalorado Relação e chave estrangeiraConjunto de valores DomínioAtributo-chave Chave primária (ou secundária)

2.2 Linhas de Produtos de Software

O reúso de funcionalidades de software tornou-se necessário com os paradigmas de softwareestruturado e orientado a objetos. Ao longo dos últimos anos, algumas pesquisas ressaltaram asvantagens em se reutilizar toda a arquitetura de software ao invés de se utilizar apenas alguns mé-todos presentes em bibliotecas do software [Cam12]. Uma abordagem que ampara essa importantetarefa é a de Engenharia de Linhas de Produtos de Software (LPSs).

A Engenharia de Linhas de Produtos de Software é um paradigma para o desenvolvimento deaplicações de software usando plataformas e customização em massa. No contexto de software,uma plataforma é uma coleção de artefatos reutilizáveis, como modelos de requisitos, modelos dearquitetura, componentes de software, planos de testes e projetos de testes. Para prover customi-zação em massa, a plataforma deve conter meios de satisfazer os requisitos de diferentes usuários.Para isso, os artefatos que podem diferir nas aplicações da linha de produtos são modelados usandovariabilidade [VDLP05]. Nesse contexto, uma linha de produto de software é definida como umconjunto de produtos, ou uma família de produtos, de software com alto grau de similaridade entresi que atendem às necessidades específicas de um determinado conjunto de usuários.


A Engenharia de Linhas de Produtos de Software divide o ciclo de vida de seu desenvolvimentoem duas fases: Engenharia de Domínio e Engenharia de Aplicação. Na Engenharia de Domínio sãodefinidas as funcionalidades comuns e variáveis para a família de produtos, que são utilizadas paraconstruir uma infraestrutura para a linha de produto, como um repositório de artefatos reutilizáveis.Na Engenharia de Aplicação utiliza-se a infraestrutura criada na fase anterior como base paraderivar produtos específicos [CB11]. A fase de Engenharia de Domínio normalmente é dividida emtrês outras fases, que são: análise do domínio, projeto do domínio e implementação do domínio. Jáa fase de Engenharia de Aplicação é dividida nas fases de projeto e de implementação de aplicaçõesindividuais. [Har02]

O conceito de variabilidade de software é fundamental para prover a reutilização de softwaree refere-se à capacidade de um sistema ou artefato de software ser modificado, personalizado ouconfigurado para ser utilizado em um contexto específico [KKL+98]. A variabilidade de um domíniopode ser expressa por meio de características, do inglês features, que são propriedades relevantes dosistema, podendo ser vistas como funcionalidades comuns ou variáveis. As características comuns,ou mandatórias, de uma LPS são aquelas que estão presentes em todos os produtos da LPS, for-mando o núcleo da LPS. Uma característica variável é aquela que pode ou não ser provida por umproduto derivado da LPS [Gom04].

Na etapa de Análise do Domínio da fase de Engenharia de Domínio, as características de umaLPS são comumente documentadas em um Diagrama de Características. Um Diagrama de Carac-terísticas é uma forma de representar todas as possíveis configurações para um produto específicoque pode ser construído a partir da LPS.

Ao descrever os artefatos de software na fase de Engenharia de Domínio por meio do Diagrama deCaracterísticas, é importante mantê-los flexíveis o suficiente para que os detalhes de implementaçãode um produto específico possam ser determinados facilmente na fase de Engenharia de Aplicação[CN01]. Para isso, são criados pontos de variação, que são locais do artefato de software em queuma decisão de projeto pode ser tomada, e variantes, que são alternativas de projeto associadas aesses pontos.

2.2.1 Abordagens Clássicas de Engenharia de Domínio

Para se criar uma família de esquemas conceituais que possa representar os dados de um de-terminado domínio de aplicação, o primeiro passo será fazer um levantamento de requisitos, que seassemelha à fase de Análise do Domínio, da Engenharia de Domínio. Dessa forma, serão estudadosalguns métodos da Engenharia de Domínio que têm potencial para serem utilizados no contextode modelagem de dados. Para facilitar a compreensão por parte de usuários especialistas em umdomínio específico, optou-se por estudar os métodos de Engenharia de Domínio que produzem comoresultado das análises diagramas mais intuitivos.

No modelo FODA (do inglês Feature-Oriented Domain Analysis) [KCH+90], o objetivo é iden-tificar as características comuns e variáveis de aplicações similares de um mesmo domínio. Essascaracterísticas são capacidades das aplicações do domínio do ponto de vista do usuário final. Ascaracterísticas em FODA são divididas em obrigatórias (ou comuns), alternativas e opcionais. EmFODA, são realizadas diversas análises, como análise de requisitos e análise de características, re-sultando em um modelo do domínio que contém as diferenças entre aplicações relacionadas [Har02].A partir do modelo do domínio, são criados componentes reutilizáveis que possibilitam o desenvol-vimento de múltiplas aplicações do domínio.

O FODA faz parte de uma abordagem baseada em modelo, que cobre tanto a fase de Engenhariado Domínio quanto de Engenharia de Aplicação. A parte de engenharia do domínio consiste emanálise do domínio, que pode ser coberta pelo FODA, projeto do domínio e implementação dodomínio [Har02].

O processo de análise de domínio pode ser dividido em três etapas [AR07]:

1. Análise do contexto: O objetivo é estabelecer os limites do domínio, a relação com outrosdomínios e o escopo da análise. No processo de levantamento dos requisitos é necessário

2.2. LINHAS DE PRODUTOS DE SOFTWARE 13

coletar informações das diferentes atividades realizadas por diversas fontes do domínio. Oresultado final dessa análise é documentado em diagramas de fluxo de dados e diagramas deestruturas.

2. Modelagem do domínio: O modelo de contexto gerado é analisado para gerar os modelosdo domínio, que podem ser dos tipos: modelo de informação, que contêm as entidades dodomínio e as relações entre elas; modelo de características, que são divididos em diagramas decaracterísticas, definições das características, regras e composição e lógica para características;modelo operacional, que descreve o controle e fluxo de dados do domínio de aplicação e osrelacionamentos entre objetos do modelo de informação e do modelo de características; edicionário da terminologia do domínio.

3. Modelagem da arquitetura: Um modelo de arquitetura de alto nível é criado a partir dosmodelos do domínio. Esse modelo será instanciado para criar aplicações individuais.

O modelo RSEB (do inglês Reuse-Driven Software Engineering Business) [JGJ97] é um métodode reuso sistemático e dirigido a modelo. São compostos conjuntos de aplicações relacionadas apartir de conjuntos de componentes reutilizáveis. O RSEB utiliza a UML [RJB99] para especifi-car sistemas de aplicações, sistemas de componentes reutilizáveis e arquiteturas em camadas. Avariabilidade entre os sistemas é expressa com pontos de variação e variantes anexadas [Har02].

O modelo FeatuRSEB (do inglês Feature RSEB) [GFd98] é uma extensão do modelo RSEBque utiliza o modelo de características similar ao do método FODA para catalogar ou indexar acomunalidade e a variabilidade capturada nos modelos do RSEB. De fato, os modelos FODA e RSEBtêm muito em comum, pois ambos são métodos dirigidos a modelos que oferecem vários modeloscorrespondendo a diferentes pontos de vista do domínio [Har02]. A diferença entre o diagrama decaracterísticas do método FODA e o do método FeatuRSEB é que o FODA contém as relaçõesAND e XOR e no FeatuRSEB é adicionada a relação OR [BHST04].

A Figura 2.6 exemplifica um Diagrama de Características para um sistema de telefones móveisbaseado na notação do método FeatuRSEB. Nesse diagrama de características, podemos identificaros componentes de telefones móveis que serão obrigatórios, ou seja, que constituem o módulo basedo diagrama, que são: tela e chamada. O componente tela tem como opções o básico, o coloridoe de alta resolução, e somente uma dessas opções poderá ser escolhida. A relação entre tela eseus filhos é um XOR (OU -Exclusivo). GPS e mídia são componentes opcionais para os telefones.O componente mídia tem duas opções, que são câmera e MP3, e pelo menos uma delas deve serescolhida. A relação entre mídia e seus filhos é um OR. Outras relações presentes no diagrama são:a relação exclui, que indica que se houver o componente GPS, então não é possível ter o componentetela do tipo básico; e a relação requer, que indica que se houver o componente de mídia do tipocâmera, então é necessário ter o componente tela de alta resolução.

Figura 2.6: Diagrama de características para sistema de telefones móveis. Adaptado de [BSRC].

Existem ainda outros métodos, como: o FORM (do inglês Feature-Oriented Reuse Method)[KKL+98], que é uma extensão do FODA para incluir as fase de Engenharia de Aplicação, o ODM


(do inglês Organization Domain Modeling) [SCK+96], que tem como foco a fase de Engenharia deDomínio de sistemas legados, o PuLSE (do inglês Product Line Software Engineering) [BFK+99],que é dividido em três fases e cada uma delas é associada com a evolução da infraestrutura da linhade produtos, e o FAST (do inglês Family-Oriented Abstraction, Specification, and Translation)[WL99], que cobre todo o processo de Engenharia de Linhas de Produtos de Software.

2.3 Considerações sobre os Conceitos Apresentados

Em relação a modelagem de banco de dados, este projeto seguirá as etapas de modelagemapresentadas na Seção 2.1, iniciando com a análise de requisitos, criando um modelo conceituale mapeando-o para um modelo físico. Pode-se considerar que as etapas de análise de requisitose modelagem conceitual serão análogas ao processo de Engenharia de Domínio da Engenharia deLinhas de Produtos de Software, enquanto que a modelagem física será análoga à Fase de Engenhariade Aplicação.

Para o modelo conceitual do banco de dados, será utilizado o modelo EER, por apresentar todasas estruturas necessárias e pela facilidade de entendimento dos seus diagramas. Para a modelagemfísica, provavelmente será utilizado o modelo relacional, combinado à linguagem SQL para gerar osbancos de dados reais.

Para representar a variabilidade de um domínio de aplicação, serão utilizados extensões dosdiagramas de características do método FeatuRSEB, por serem diagrama completos, que contêmtodos os tipos de relações necessários para a proposta.

Capítulo 3

Trabalhos Relacionados

Neste capítulo serão apresentados alguns trabalhos relacionados ao projeto de mestrado propostoneste texto. Esses trabalhos foram separados em dois tópicos. O primeiro trata de trabalhos queapresentam abordagens flexíveis ou evolutivas para modelagem conceitual de banco de dados. E osegundo aborda os trabalhos que aplicaram o paradigma de Linhas de Produtos de Software parao domínio de banco de dados.

3.1 Modelagem Conceitual de Banco de Dados

Um dos principais problemas encontradas na modelagem de banco de dados é conseguir lidarcom as mudanças ou diferenças de requisitos que acontecem quando um mesmo modelo de bancode dados é utilizado por mais de um usuário ou grupo de usuários dentro de um determinadodomínio de aplicação. Os trabalhos encontrados na literatura que abordam esse problema propõemesquemas de dados mais flexíveis para apoiar as alterações que possam ocorrer no banco de dadosem algum momento do tempo, quando já existe o modelo físico. Dessa forma, essas abordagenstratam o problema considerando o versionamento do banco de dados.

Uma das abordagens utilizadas cria uma extensão do modelo entidade-relacionamento (ER) deforma que em um mesmo diagrama ER seja representada uma versão anterior e a versão atual dosrequisitos do banco de dados. Portanto, num mesmo diagrama é possível identificar quais foramas alterações feitas de uma versão para a outra. No trabalho de Liu et al. [LCC94] é apresentadoo diagrama EVER (do inglês EVolutionary ER), que herda as construções gráficas usadas nosdiagramas ER para especificar as relações de derivação entre versões do esquema, as relações entreos atributos e as condições para manter versões consistentes do banco de dados.

Outra abordagem consiste em fazer uma previsão das modificações que poderão ocorrer nomodelo conceitual de banco de dados e a partir dessas modificações fazer um mapeamento dasmesmas para o modelo físico do banco de dados. O trabalho de Roddick et al. [RCR93] apresentauma taxonomia de mudanças aplicáveis ao modelo entidade relacionamento juntamente com seusefeitos no modelo relacional subjacente expressados em termos de uma segunda taxonomia. Oconjunto de operações atômicas propostas para serem aplicadas ao modelo relacional devem resultarem um banco de dados consistente e, na medida do possível, reversível.

Uma terceira abordagem diz respeito a utilizar modelos mais genéricos em qualquer etapa damodelagem do banco de dados, tanto conceitual quanto física, e para todo tipo de esquemas,como o modelo entidade-relacionamento, o modelo relacional e o modelo orientado a objetos. Notrabalho de Hainaut et al. [HCMD92] é apresentado o modelo TRAMIS, que é uma extensão domodelo entidade-relacionamento para expressar estruturas tanto conceituais quanto técnicas. Éproposta uma abordagem diferente das tradicionais, na qual tanto os projetistas novatos quanto osexperientes podem produzir esquemas de banco de dados de acordo com suas próprias estratégias.Em particular, o TRAMIS é uma ferramenta que oferece aos seus usuários tanto um alto grau deflexibilidade quanto a possibilidade de restringir quando necessário. No trabalho de Proper [Pro97]é proposto um universo de esquemas de dados flexíveis que permite descrever esquemas de dados

15

16 CAPÍTULO 3. TRABALHOS RELACIONADOS

subjacentes em todos os estágios de seu desenvolvimento.Os trabalhos que exploram essas três abordagens têm como principal objetivo propor modelos

de dados flexíveis para trabalhar com as mudanças que ocorrem entre versões do banco de dados.Por outro lado, o projeto de mestrado apresentado nesse texto busca lidar com as diferenças derequisitos dentro de um mesmo domínio de aplicação em nível de modelagem conceitual, propondoum modelo onde possam ser especificadas essas diferenças ao mesmo tempo em que é destacado osrequisitos comuns entre as aplicações.

3.2 Uso de Linhas de Produtos de Software em Banco de Dados

Os artefatos criados e reusados nas linhas de produtos de software (LPSs) geralmente são mo-delos de requisitos, componentes de software e planos de testes. E, embora muitos produtos desoftware façam uso intensivo de dados que são mantidos em bancos de dados, há poucos trabalhosque se dedicam a propor maneiras de se lidar com os bancos de dados nas LPSs. Abaixo são apre-sentados três trabalhos que propõem abordagens usando o paradigma de LPS com foco em Bancode Dados.

O trabalho de Bartholdt et al. [BOR09] define uma abordagem para a modelagem e integraçãode dados em LPSs que usam desenvolvimento dirigido por modelos (MDSD – Model Driven SoftwareDevelopment). Nessa abordagem, a modelagem dos dados é feita por meio de diagramas da UML2XMI (Unified Modeling Language – XML Metada Interchange), de forma integrada à modelagemdas características da LPS.

Na abordagem proposta no trabalho de Zaid e Troyer [AZDT11], a modelagem dos dados tam-bém é feita conjuntamente à das características dos produtos de software da linha: todo item dedado que aparece no modelo deve estar associado a uma característica de software. E uma carac-terística que tem um item de dado associada a ela é chamada no modelo proposto pelo autores decaracterística de persistência. Segundo as autores, a abordagem pode ser aplicada sobre qualquertipo de modelo conceitual de dados.

No trabalho de Siegmund et al. [SKR+09], a ideia é decompor os esquemas em termos de caracte-rísticas e para isso são criados dois tipos de decomposição: a decomposição física e a decomposiçãovirtual. Na decomposição física, elementos do esquema de dados são armazenados em arquivosseparados, sendo um arquivo por característica. Já na decomposição virtual, os elementos do es-quema conceitual não são fisicamente separados, mas são apenas anotados, ou seja, os elementospertencentes a uma característica são deixados em um único esquema com outros elementos, massão destacados.

Os trabalhos descritos acima se baseiam na criação de diagramas de características de dados apartir de modelos conceituais de dados associados a diagramas de características de software. Já otrabalho de Khedri e Khosravi [KK13] não se baseia em diagramas de características, mas sim natécnica delta-oriented programming. Na abordagem proposta pelos autores, os dados são sempredescritos no nível de implementação (como comandos de definição de dados da SQL). O modelo dedados de um produto de software é gerado por meio da adição ao módulo núcleo de um módulo dedados delta para cada uma das características escolhidas para o produto.

Esses trabalhos mostram que é viável estender os métodos e ferramentas da Engenharia de Linhasde Produto de Software para a aplicação em Bancos de Dados. Entretanto, diferentemente do queocorre na proposta de projeto apresentada neste texto, as abordagens descritas nesses trabalhosnão tinham como alvo a criação de famílias de bancos de dados, mas sim a criação de famílias deaplicações que fazem uso de bancos de dados. Portanto, para esses trabalhos, o banco de dadosé apenas mais um artefato de apoio, e não o produto final. Além disso, a família de modelosconceituais que será criada neste projeto é extensível. Os usuários finais poderão incorporar novascaracterísticas ao modelo da família, para que ela consiga lidar com novos tipos de experimentosnão considerados na família inicial.

Capítulo 4

Proposta

4.1 Método

Este projeto de mestrado tem como objetivo propor soluções para o problema de representaçãode dados em domínios de aplicação que apresentam alto grau de variabilidade estrutural dos dados.Para a modelagem conceitual dos dados, o projeto desenvolverá uma técnica para a criação defamílias de esquemas conceituais de dados, capazes de representar dados variáveis em diferentesdomínios de aplicação.

Como as abordagens clássicas de Linhas de Produtos de Software não lidam particularmente coma variabilidade de dados e, mais especificamente, em nível de modelagem conceitual, este trabalhopropõe o uso de um novo tipo de diagrama, que estende os Diagramas de Características utilizadosna fase de Análise de Domínio de forma a possibilitar a representação da variabilidade de dados dodomínio. O novo diagrama proposto, chamado Diagrama de Características de Banco de Dados,será explicado com mais detalhes no Capítulo 5. Para criar uma família de esquemas conceituaisde banco de dados a partir do uso desse diagrama, será necessário seguir um conjunto de passoscuja versão preliminar é apresentada na Seção 5.2.

Para que um esquema conceitual específico (membro de um família de esquemas) possa ser usadopara criar um banco de dados real, é preciso que ele seja mapeado em um esquema de modelo físicoou de implementação que, por sua vez, será mapeado em comandos em uma linguagem de definiçãode dados (DDL - data definition language), como a linguagem SQL (Structured Query Language).Neste trabalho, usaremos modelos de implementação, como o Modelo Relacional ou o Modelo deDados de Objetos. O mapeamento de um modelo conceitual para um modelo de implementaçãopode ser feito de forma automática. Por exemplo, há vários algoritmos de mapeamento de esquemasentidade-relacionamento em esquemas relacionais. A Seção 2.1.3 apresentou um desses algoritmosde mapeamento.

Uma vez que já se tenha um banco de dados criado a partir de um esquema específico da família,pode-se também desejar que a estrutura do banco de dados seja incrementada, a fim de que elepossa armazenar dados de novos tipos de dados. No nível da modelagem conceitual, isso poderá serfeito estendendo-se a família de esquemas. Para atender a essa demanda no nível físico, o projetodefinirá mapeamentos que realizem a “evolução” de um esquema de implementação de origem em umoutro esquema de destino. A partir desses mapeamentos, será possível gerar de forma automáticacomandos em DDL para a modificação da estrutura dos bancos de dados. Os mapeamentos poderão,inclusive, definir operações de manipulação dos dados quando as modificações a serem feitas paraestender a estrutura de um banco demandarem mudanças de grande impacto em sua estruturaatual.

Para atender aos requisitos acima, será desenvolvida uma ferramenta de software (provavelmentena linguagem Java, na forma de plugin para a plataforma Eclipse) onde poderão ser criados osmódulos de dados em nível de esquemas conceituais de banco de dados. Os módulos criadospoderão então ser utilizados para criar Diagramas de Características de Banco de Dados. Nessamesma ferramenta, haverá a opção de gerar um script SQL para realizar a criação ou a modificação

17

18 CAPÍTULO 4. PROPOSTA

de um esquema físico de banco de dados. Essa ferramenta servirá como auxílio para a etapa devalidação da técnica de modelagem, bem como para facilitar o seu uso na prática.

Para as etapas envolvidas no mapeamento de um esquema conceitual específico em um modelode implementação e na posterior criação (ou modificação) de um banco de dados por meio decomandos em DDL, é possível traçar uma correspondência com a Engenharia de Aplicação, que éo processo que sucede a Engenharia de Domínio nas LPSs.

4.1.1 Aplicação Específica

A nova técnica de modelagem proposta neste trabalho será usada em um domínio de aplicaçãoreal: gerenciamento de dados experimentais de neurociência no escopo do projeto de pesquisaNeuroMat (apresentado no Capítulo 6). Esse estudo de caso possibilitará avaliar a viabilidadee os benefícios do uso da técnica e das ferramentas de software desenvolvidas neste projeto numcontexto prático, além de contribuir com a comunidade de neurociência por meio da construção deuma família de esquemas conceituais de dados capaz de representar de forma padronizada dadosdos tipos de experimentos mais frequentemente usados por neurocientistas.

Uma vez definida a família inicial de esquemas de dados para experimentos em neurociência,é desejável que essa família possa ser estendida facilmente sempre que necessário, para acomodartanto tipos de experimentos que não haviam sido inicialmente considerados quanto novos tiposde experimentos que possam surgir no futuro. Além disso, deseja-se que as extensões possam serfeitas pelos próprios neurocientistas, sem a necessidade da intervenção de um usuário especialistaem Computação. Para isso, será criada uma notação (ou, mais precisamente, uma linguagem demodelagem de domínio específico), que encapsulará parte da complexidade associada à criação deesquemas conceituais de bancos de dados e de diagramas de características de banco de dados.

Os construtores que serão disponibilizados na notação permitirão que extensões sejam feitas apartir dos pontos de variação, mas garantindo que as mudanças não comprometam o módulo basedefinido para os esquemas da família. A intenção disso é possibilitar que a família de esquemas dedados cresça, mas de forma padronizada e controlada, respeitando critérios definidos para garantira qualidade dos dados de experimentos mantidos nos bancos de dados criados a partir dos esquemasda família.

4.2 Validação e Avaliação

Para avaliar qualitativamente a técnica de modelagem, a notação para neurocientistas e osesquemas de bancos de dados criados a partir delas, serão usados métodos empíricos da Engenhariade Software comumente aplicados na avaliação da qualidade de linhas produtos de software. Oscritérios que são considerados mais importantes na análise da qualidade de LPSs se relacionam aosuporte a variabilidade, flexibilidade, manutenibilidade e capacidade de evolução [VDLP05]. Essescritérios também são aplicáveis a esquemas de dados e serão usados para avaliar a qualidade dasfamílias de esquemas de dados conceitual e de implementação a serem criadas neste projeto demestrado.

Segundo trabalhos de revisão sistemática recentes [ABG13, CB11], os trabalhos da área deengenharia de LPSs que apresentam avaliações mais rigorosas de seus métodos e resultados fazemessas avaliações por meio de experimentos controlados e estudos de casos. Neste projeto, serãousados como estudos de casos os diferentes tipos de experimentos em neurociência realizados dentrodos laboratórios associados ao projeto NeuroMat.

Os modelos conceituais, a notação para a extensão desses modelos e os esquemas físicos debancos de dados desenvolvidos neste projeto para o estudo de caso (Capítulo 6) poderão ser testadose validados pelos neurocientistas associados ao NeuroMat. Para isso, serão desenvolvidos protótiposde interface de cadastro e consulta de dados que possibilitarão que os cientistas interajam com osbancos de dados gerados de forma automática a partir dos modelos propostos no projeto. Osexperimentos controlados e estudos de caso realizados serão conduzidos de acordo com diretrizes já

4.2. VALIDAÇÃO E AVALIAÇÃO 19

bem estabelecidas na comunidade de Engenharia de Software [JP05,RH09].

20 CAPÍTULO 4. PROPOSTA

Capítulo 5

Resultados Preliminares

5.1 Diagramas de Características de Banco de Dados

Da mesma forma que os diagramas de características apoiam a criação de produtos de soft-ware personalizados e extensíveis, eles podem ser utilizados na modelagem de banco de dados parapermitir que o projetista de banco de dados crie esquemas personalizáveis que possam ser facil-mente estendidos para atender às necessidades específicas de algum usuário. Entretanto, a fimde possibilitar o uso dos diagramas de características no projeto conceitual de banco de dados, énecessário redefinir o conceito de característica (do inglês, feature), relacionando-o aos objetos dedados conceituais, como: tipo de entidade, atributo e tipo de relacionamento.

Dessa forma, estamos propondo a criação dos Diagramas de Características de Banco de Dados– chamados Database Feature Diagrams (DBFDs) em inglês 1 – uma extensão dos diagramas decaracterísticas do método featuRSEB dedicada à modelagem conceitual de banco de dados. UmDBFD é sobretudo composto de três tipos de elementos: módulos, relações e anotações.

Em Linhas de Produtos de Software, a seleção de características no diagrama resulta em umnovo produto de software personalizado contendo essas características. De maneira análoga, aseleção de módulos de dados no diagrama DBFD resulta em um esquema conceitual de banco dedados personalizado contendo esses módulos e as relações que podem existir entre eles.

Um módulo de dados é o artefato reutilizável em um DBFD (correspondente ao conceito de‘característica’ dos diagramas de características clássicos) e pode ser definido como uma partiçãodo modelo conceitual de banco de dados, agrupando objetos de dados que estão fisicamente ousemanticamente relacionados. As relações expressam as dependências e restrições existentes entreos módulos. Já as anotações são uma característica especial que foi introduzida nos DBFDs paraaperfeiçoar a expressividade das relações.

A Figura 5.1 mostra um exemplo de DBFD. Na notação gráfica, um módulo de dados é re-presentado com um retângulo contendo seu nome dentro, enquanto as relações são arcos rotuladosligando os módulos. As anotações são expressas textualmente e aparecem anexadas ao diagramagráfico.

Normalmente, quando um módulo de dados é selecionado no DBFD, um conjunto de objetos dedados conceituais vai ser criado no esquema conceitual. Se isso não acontece, então esse módulo échamado módulo de dados vazio e é graficamente representado de forma similar aos outros módulos,mas com seu nome sublinhado (por exemplo, Shopping online). Um DBFD tem também ummódulo especial, o módulo raiz, que se refere à família de esquemas conceituais modeladas nodiagrama por completo e é desenhado no topo do DBFD (por exemplo, Shopping online). Omódulo raiz pode ser visto como um módulo vazio, já que ele não gera nenhuma modificação noesquema conceitual.

1Neste texto, estamos empregando um nome em inglês – Database Feature Diagram (DBFD) – para a nova técnicade modelagem proposta pois esse foi o nome atribuído a ela em um artigo que foi recentemente submetido para oSimpósio Brasileiro de Banco de Dados (SBBD) 2015.

21

22 CAPÍTULO 5. RESULTADOS PRELIMINARES

Figura 5.1: Diagrama de Características para um sistema de compras online. Adaptado de [Seg].

5.1.1 Relações nos DBFDs

DBFDs podem expressar os mesmos tipos de relações encontradas nos Diagramas de Caracte-rísticas clássicos. Esses tipos podem ser categorizados em: relações consiste-em, que ligam módulospais aos módulos filhos usados para compô-los, e relações de restrição, que definem ligações cru-zando a árvore (isto é, não necessariamente relações parentais) entre pares de módulos. Existemquatro tipos de relações consiste-em (todas elas ilustradas na Figura 5.1):

• Composição obrigatória – denota um módulo filho que é necessário. É graficamente represen-tado por uma reta terminando com um círculo preenchido ligando o pai ao filho obrigatório(por exemplo, Catálogo).

• Composição opcional – denota um módulo filho que é opcional. É graficamente representadopor uma reta terminando com um círculo vazio ligando o pai ao filho opcional (por exemplo,Busca).

• Composição OU – denota que pelo menos um dos módulos filhos deve ser selecionado. Édesenhado com um ângulo preenchido no módulo pai unindo os arcos de ligação dos filhos(por exemplo, entre o módulo Pagamento e seus filhos).

• Composição OU-Exclusivo, também chamada de composição alternativa – denota que um esomente um dos módulos filhos deve ser selecionado. É desenhado como um ângulo vazio nomódulo pai unindo os arcos de ligação dos filhos (por exemplo, entre o módulo Segurança eseus filhos).

Existem dois tipos de relações de restrição que podem ser definidas a partir de um módulo deorigem A para um módulo de destino B:

• Requer – denota que se o módulo A é selecionado, então o módulo B também deve ser sele-cionado. É desenhado com uma seta pontilhada unindo dois módulos (por exemplo, Cartãode Crédito requer Alta (Segurança)).

• Exclui – denota que se o módulo A é selecionado, então o módulo B não pode ser selecionado(isto é, os módulos A e B não podem ser parte do mesmo esquema conceitual). É desenhadocom uma seta tracejada unindo dois módulos (por exemplo, Homem exclui Mulher).

Como mostrado na Figura 5.1, toda relação é graficamente representada como um arco rotuladopartindo de um módulo de origem para um módulo de destino. O rótulo de uma relação é seu nomede identificação. Por esse motivo, um rótulo de relação deve ser único no DBFD.

5.1.2 Anotações nos DBFDs

As anotações são um recurso exclusivo dos DBFDs, isto é, elas não existem nos diagramas decaracterísticas clássicos. Uma anotação está sempre associada a uma relação e tem como propósito

5.1. DIAGRAMAS DE CARACTERÍSTICAS DE BANCO DE DADOS 23

descrever as modificações que devem ser realizadas nos esquemas conceituais dos módulos envol-vidos na relação a fim de criar esquemas conceituais personalizados. Cada anotação denota umamodificação atômica, ou seja, a inclusão, atualização ou exclusão de um único objeto de dadosno esquema conceitual de um módulo de dados. Cada relação pode ser associada a várias anota-ções, mas uma anotação pertence a somente uma relação. Por exemplo, as anotações no DBFD daFigura 5.1 serão feitas com base nas relações representadas pelos rótulos de R1 até R8.

Neste trabalho, nós adotamos o modelo Entidade Relacionamento Estendido (EER) [EN10]para o projeto dos esquemas conceituais. Portanto, um módulo de dados no DBFD é um modeloEER e os tipos de objetos de dados que podem ser criados ou modificados nos módulos de dadospor meio das anotações são os mesmos existentes nos modelos EER: tipos de entidade, tipos derelacionamento, atributos, especializações e categorizações.

Anotações são declarações textuais que seguem um formato bem definido. A Seção 6.3.2 mostraalguns exemplos de anotações. A sintaxe das anotações é inspirada nos comandos de modificaçãode esquemas da linguagem SQL e está definida na seguinte gramática 2:

anotação = rótulo_relação, ":", (atributo | relacionamento | especialização | categorização), ";"

atributo = "ALTER", (módulo_entidade | módulo_relacionamento), modificação_de_atributomodificação_de_atributo = adicionar_atributos | remover_atributos

módulo_entidade = "( M ", nome_módulo, " - E ", nome_entidade, ")"módulo_relacionamento = "( M ", nome_módulo, " - R ", nome_relacionamento, ")"

adicionar_atributos = "ADD ATTRIBUTE", lista_de_atributoslista_de_atributos = definição_atributo, {",", definição_atributo}definição_atributo = valor_único | multivaloradovalor_único = tipo_atributo, [ "KEY" ]multivalorado = "{", tipo_atributo, "}"tipo_atributo = (simples | composto)simples = nome_novo_atributocomposto = nome_novo_atributo, "(", tipo_atributo, {",", tipo_atributo}, ")"

remover_atributos = "DROP ATTRIBUTE", nome_atributo, {",", nome_atributo}

relacionamento = "ADD RELATIONSHIP", nome_novo_relacionamento, "BETWEEN", módulo_entidade, "AND",módulo_entidade, cardinalidade, [participação], ["ATTR =", lista_de_atributos]

cardinalidade = "1:1" | "1:N" | "N:1" | "M:N"participação = "PARTIAL:PARTIAL" | "PARTIAL:TOTAL" | "TOTAL:PARTIAL" | "TOTAL:TOTAL"

especialização = "ADD SPECIALIZATION", nome_especialização, "FROM SUPERCLASS", módulo_entidade,"TO SUBCLASS", módulo_entidade, {",", módulo_entidade} ["DISJOINT" | "OVERLAPPING"]

categorização = "ADD CATEGORY", nome_categoria, "TO SUBCLASS", módulo_entidade,"FROM SUPERCLASS" módulo_entidade, {",", módulo_entidade}

rótulo_relação = ? rótulo de uma relação do DBFD ?nome_módulo = ? nome de um módulo de dados da relação anotada ?nome_entidade = ? nome de um tipo de entidade do módulo associado ?nome_relacionamento = ? nome de um tipo de relacionamento do módulo associado ?nome_novo_relacionamento = ? nome de um tipo de relacionamento que ainda não existe no esquema ?nome_atributo = ? nome de um atributo do objeto de dados associado ?nome_novo_atributo = ? nome de um atributo que ainda não existe no esquema ?nome_especialização = ? nome de uma especialização no esquema de banco de dados ?nome_categoria = ? nome de uma categoria no esquema de banco de dados ?

Algumas observações adicionais podem ser feitas sobre as anotações. Primeiro, os atributosadicionados a tipos de entidades ou tipos de relacionamentos podem ser simples ou compostos,e de valor único ou multivalorados. Além disso, um atributo de valor único pode ser definidocomo um atributo chave. Segundo, um tipo de relacionamento, especialização ou categorizaçãodefinido por meio de uma anotação não precisa envolver tipos de entidades dos dois módulos dedados ligados pela relação sobre a qual a anotação foi feita. Portanto, uma anotação pode serutilizada para relacionar tipos de entidades de um mesmo módulo. E, por último, o grau dos tiposde relacionamento criados por meio de anotações é sempre dois.

2A gramática das anotações está definida no formalismo Backus-Naur estendido.

24 CAPÍTULO 5. RESULTADOS PRELIMINARES

5.2 Projetando uma Família de Esquemas Conceituais de Banco deDados

Os Diagramas de Características de Banco de Dados (DBFDs) introduzidos na Seção 5.1 podemser usados para modelar a variabilidade que pode existir nos esquemas conceituais de banco de dadosde organizações de um mesmo domínio de aplicação. Uma família de esquemas conceituais de bancode dados compreende todas as variações possíveis de esquemas conceituais para um dado domínio.Por esse motivo, um DBFD denota uma família de esquemas conceituais.

A criação de uma família de esquemas conceituais de banco de dados começa com a identificaçãodos módulos de dados pertencentes ao domínio de aplicação considerado. A fim de fazer isso,primeiro o projetista do banco de dados deve coletar todos os requisitos de dados reportados pelosusuários de diferentes organizações do domínio de aplicação. Nesse estágio, outra tarefa primordialé identificar as semelhanças e as variações existentes nas organizações em relação aos seus requisitosde dados. Então, o projetista deve agrupar os requisitos de dados de acordo com os conceitos dedados a que eles se referem.

Cada grupo de requisitos de dados relacionados vai gerar um módulo de dados. Eventualmente,será necessário dividir um módulo de dados em mais módulos para separar requisitos que são comunspara todos os usuários de outros requisitos que são específicos para apenas alguns usuários. E paracada módulo de dados, um modelo conceitual EER deve ser desenhado. Neste ponto, é importantelembrar que os módulos de dados são partições do esquema de banco de dados, então eles nãopodem ter intersecções (ou seja, um objeto de dados que aparece em um dado módulo não podeaparecer em outro módulo do DBFD).

Depois da identificação e definição dos módulos de dados, o próximo passo é a criação do DBFD.Para criar o DBFD, o projetista deve primeiro identificar as dependências que existem entre osmódulos de dados e então expressá-las por meio de relações consiste-em e de restrição (definidasna Seção 5.1.1). Cada módulo de dados que se refere aos requisitos de dados que são comuns paratodos os usuários do domínio de aplicação deve ser definido como um módulo de dados base noDBFD. Um módulo de dados base deve ser um descendente obrigatório do módulo raiz do DBFD 3.Os módulos de dados base no DBFD definem o que é comum em todos os esquemas conceituais dafamília.

As composições opcionais ou alternativas dos módulos de dados no DBFD são projetadas pararepresentar o que pode ser selecionado e combinado de diferentes maneiras para criar esquemasconceituais personalizados. Quando módulos opcionais são adicionados aos módulos base, esque-mas conceituais específicos são criados para representar partes do domínio de aplicação. Nesseestágio, alguns módulos de dados vazios podem também ser introduzidos no DBFD para expressarmodificações de dados que devem ser feitas em relação a outros módulos não-vazios a fim de satis-fazer um dado conjunto de requisitos de dados que não geram novos tipos de entidades no esquemaconceitual.

Uma vez que as relações de um DBFD são definidas, elas podem ser enriquecidas com as ano-tações (como descrito na Seção 5.1.2). As anotações ajudam a garantir a semântica apropriadapara os módulos de dados quando eles são usados integrados com outros, para compor um es-quema de dados específico. Por meio das anotações, o projetista pode, por exemplo, adicionar aoesquema conceitual relacionamentos, especializações e categorizações envolvendo tipos de entidadesde diferentes módulos.

É importante notar que uma família inicial de esquemas de dados pode ser facilmente estendidatoda vez em que um novo requisito de dados aparecer no domínio de aplicação. Para isso, énecessário apenas adicionar novos módulos de dados no DBFD da família de esquemas e conectá-los aos módulos pré-existentes, por meio de relações e anotações.

3Um descendente obrigatório do módulo raiz é um módulo que está conectado à raiz por meio de um caminhocontendo apenas composições obrigatórias.

Capítulo 6

Estudo de Caso: Dados Experimentaisde Neurociência

O método introduzido na Seção 5.2 está sendo utilizado para criar e evoluir esquemas conceituaisde banco de dados para um domínio do mundo real: dados experimentais de neurociência, coletadosno escopo do projeto de pesquisa apresentado no Apêndice A – o Centro de Pesquisa, Inovação eDisseminação para Neuromatemática (NeuroMat) 1.

6.1 Apresentação do Domínio

A neurociência corresponde ao estudo científico do sistema nervoso, visando compreender suaestrutura, seu desenvolvimento, seu funcionamento, sua evolução, a relação entre o comportamentoe a mente, e também suas alterações. Essa área tem apresentado um crescente desenvolvimento,envolvendo um número cada vez maior de cientistas interessados em realizar experimentos que osauxiliem a melhor entender o funcionamento do cérebro humano. Os experimentos em neurociênciainvestigam a correlação entre os sistemas cerebrais e a atividade mental alterada ou saudável esão realizados por meio de instrumentos específicos, testes manuais e computadorizados, rotinascomportamentais e questionários dirigidos.

Entre os diferentes tipos de experimentos realizados em neurociência, os eletrofisiológicos e deneuroimagem em particular sempre envolvem a coleta de dados em formato digital. Experimentoseletrofisiológicos envolvem o estudo de potenciais elétricos gerados pelo cérebro por meio da coletade sinais da atividade cerebral ou muscular de humanos ou outros animais submetidos a condiçõesexperimentais específicas (como, por exemplo, a exposição a um estímulo sonoro ou a execuçãode uma tarefa motora). Exemplos de experimentos de eletrofisiologia são a Eletroencefalografia(EEG), a Estimulação Magnética Transcraniana (TMS) e a Eletromiografia (EMG).

Experimentos de neuroimagem consistem na utilização de aparelhos compostos por um magnetosupercondutor e bobinas, que transmitem ondas de radiofrequência, formando juntos um campomagnético intenso, ativando os átomos de hidrogênio. Quando desligados os pulsos de rádio-frequência, esses átomos liberam energia que é captada por antenas receptoras e convertida emsinais digitais que são traduzidos em imagens estruturais de alta definição do cérebro. Exemplosdesse tipo de experimento são a Ressonância Magnética (MRI) e Ressonância Magnética Funcional(fMRI) [PFH+08]

Em um experimento em neurociência, os sujeitos (humanos ou animais) geralmente são se-parados em grupos. Cada grupo pode ser submetido a um conjunto de condições experimentaisespecíficas. Mas pode-se ter experimentos em que um mesmo conjunto de condições experimentaisé aplicado sobre diferentes grupos de sujeitos. Uma prática frequente dos neurocientistas é extrairnovos conhecimentos a partir da comparação dos resultados obtidos para diferentes grupos de umexperimento. Cada tipo de experimento envolve uma preparação específica para sua realização,

1Sítio Web do NeuroMat: http://neuromat.numec.prp.usp.br/.

25

http://neuromat.numec.prp.usp.br/

26 CAPÍTULO 6. ESTUDO DE CASO: DADOS EXPERIMENTAIS DE NEUROCIÊNCIA

como, por exemplo, configurações no equipamento de coleta do sinal e a colocação de sensores(eletrodos) em locais previamente definidos do corpo dos sujeitos do experimento.

Todas as definições sobre um experimento são chamadas pelos cientistas de protocolo experimen-tal ou desenho do experimento. As coletas de dados podem se referir tanto aos sinais ou imagenscapturados dos sujeitos e registrados em meio digital com o auxílio de equipamentos como o de EEGou RMI, quanto a medições ou anotações manuais sobre o comportamento observado dos sujeitos.Para que um cientista possa fazer uma análise correta dos dados coletados a partir de experimentosem neurociência, ele precisa saber dos detalhes do protocolo experimental usado na coleta dos dadose também ter conhecimento das informações ortogonais à realização do experimento.

Frequentemente, cientistas armazenam digitalmente os dados de seus experimentos como arqui-vos comuns, mantidos no sistema de arquivos de um computador. Esses dados, quando digitalizados,acabam virando arquivos texto ou planilhas, sem nenhum formato padrão. Essa estrutura de arma-zenamento dificulta a manutenção, a recuperação (busca), o compartilhamento e o reúso dos dados,principalmente quando o volume de dados coletados começa a crescer.

A representação e o armazenamento digital de dados de experimentos em neurociência impõediversos desafios. O principal deles é a grande variabilidade que pode existir nas estruturas dosprotocolos experimentais. Além disso, não há um consenso na comunidade científica sobre quaissão os tipos de dados que são indispensáveis para se reportar um experimento em neurociência.Também há a dificuldade em se definir um modelo de representação de dados em formato digitalque possibilite um armazenamento físico eficiente e que seja, ao mesmo tempo, de fácil entendimentopara neurocientistas (i.e, usuários que não necessariamente são especialistas em computação). Aindanão existem propostas que lidem apropiadamente com esses desafios e que tenham se tornado umareferência para a comunidade de neurociência.

6.2 Representação e Armazenamento de Dados em Neurociência

Na última década, a comunidade de neurociência despertou para a importância da criação emanutenção de bancos de dados que apoiem as pesquisas conduzidas nessa área. Consórcios eprojetos foram criados [Nem, Car], com o objetivo de desenvolver padrões para a representaçãode dados e ontologias no domínio da neurociência, e também repositórios que integrem dadosprovenientes de fontes heterogêneas e os disponibilizem para a comunidade científica (em algumasvezes de forma pública, em outras vezes por meio de acesso controlado).

Apesar da crescente quantidade de iniciativas relacionadas à coleta e organização de dados emneurociência, ainda há muitas limitações nas soluções que vêm sendo empregadas atualmente. Umaavaliação informal feita sobre bancos de dados bastante conhecidos na comunidade de neurociência(como os listados na Wikipédia [wik]) identificou algumas deficiências frequentes. Além de muitasvezes não serem de acesso público e não apresentarem quantidade significativa de dados, esses bancosde dados são muito específicos para determinados tipos de paradigmas de experimentos, como,por exemplo, cognição e memória, e com isso não têm a flexibilidade necessária para acomodarexperimentos mais variados. E, também, a maioria desses bancos de dados funcionam como uma“federação” de conjuntos heterogêneos de dados, ou seja, eles agrupam dados coletados em diferentesprojetos – com qualidade variável e, muitas vezes, armazenados em estruturas diferentes – e nãoprovêm uma visão unificada dos dados. Isso dificulta o reuso dos dados para a descoberta automáticade novos conhecimentos.

Segundo Kötter [Köt01], outra dificuldade está na quantidade e diversidade de dados que sãonecessários para a análise do complexo sistema cerebral. A análise manual de grandes volumes dedados é impraticável, o que vem obrigando os neurocientistas a recorrerem a sistemas computaci-onais que auxiliem suas pesquisas. Cenários desse tipo em outros domínios da biologia (como agenética) impulsionaram a criação de padrões para a representação de dados e o desenvolvimentoda área de bioinformática.

Portanto, mesmo considerando os avanços já alcançados, existe ainda um grande desafio que aárea de neurociência precisa transpor para que possa se beneficiar de maneira mais plena do uso

6.3. APLICANDO OS DBFDS NA MODELAGEM DE DADOS EXPERIMENTAIS DE NEUROCIÊNCIA27

de sistemas computacionais: estabelecer padrões para a representação e armazenamento de da-dos dados coletados ou gerados em experimentos, bem como para os dados de proveniência dessesexperimentos. Esses padrões possibilitariam a interoperalibidade nas ferramentas de software desen-volvidas para o domínio, facilitariam a criação e manutenção dos repositórios e o compartilhamentoe reúso dos dados.

Apesar da ausência de padrões, já existem iniciativas relacionadas à criação de diretrizes quedefinem quais são os dados que um pesquisador precisa reportar quando publica os resultadosde um experimento em neurociência. Exemplos de diretrizes desse tipo são a MINI (MinimumInformation about a Neuroscience Investigation) [GOS+09] e a MINEMO (Minimal Information forNeural Electromagnetic Ontologies) [FSM+11]. A MINI e MINEMO podem ser vistas como checklists de informações que devem ser associadas a dados coletados em experimentos de eletrofisiologia.Tanto a MINI quanto a MINEMO estão associadas ao projeto MIBBI (Minimum Information forBiological and Biomedical Investigations) [TFS+08], que foi o projeto pioneiro que visava coordenaro desenvolvimento de diretrizes para reportar metadados científicos.

As check lists geralmente incluem informações que são consideradas indispensáveis para a análisedos dados coletados e para a compreensão do experimento realizado. Entretanto, essas informaçõespodem não ser suficientes para possibilitar que o experimento seja reproduzido ou que os dados delesejam reusados em outros contextos. Portanto, elas não podem ser consideradas modelos completosde representação e armazenamento de dados.

6.3 Aplicando os DBFDs na Modelagem de Dados Experimentaisde Neurociência

O estudo de caso apresentado nesta seção não abrange todos os requisitos de dados coletadoscom os pesquisadores e instituições associados ao NeuroMat, já que esse é um trabalho ainda emandamento. Os resultados preliminares apresentados aqui têm como objetivo ser uma prova deconceito dos DBFDs e do método introduzido na Seção 5.2. Os requisitos de dados consideradosnessa prova de conceito são os descritos na Seção 6.3.1. Mas vale ressaltar que ainda serão realizadasoutras análises de requisitos conforme as necessidades do projeto.

6.3.1 Uma Breve Descrição dos Requisitos de Dados

Experimentos em neurociência são aplicados sobre grupos de sujeitos (por exemplo, participantesdos estudos). Sujeitos podem ser humanos e animais não humanos. Alguns laboratórios realizamexperimentos envolvendo somente sujeitos humanos, enquanto que outros realizam experimentosenvolvendo somente não humanos. Cada um desses dois tipos de sujeitos tem seus próprios atributos.Por exemplo, a língua nativa é um atributo exclusivo de sujeitos humanos, enquanto que espécie egênero somente fazem sentido para não humanos. Para participar de um experimento, um sujeitohumano deve assinar um termo de consentimento.

Os experimentos geralmente seguem um paradigma, que se refere aos métodos de pesquisautilizados pelos cientistas para alcançar seus objetivos experimentais. Cada grupo de sujeitos deum experimento é associado a um protocolo experimental, que pode ser visto como uma “receita”para executar um experimento. Um protocolo experimental pode ser modelado como um fluxo detrabalho (do inglês, workflow), onde cada passo pode ser um único componente, uma sequência decomponentes ou um bloco de componentes paralelos.

Um único componente corresponde a uma tarefa a ser executada pelo sujeito, à apresentaçãode um estímulo, a uma pausa, a uma instrução que será dada ao sujeito, ao preenchimento deum questionário ou à coleta de dados. Existem diferentes tipos de coletas de dados que podemser feitas nos experimentos de neurociência: sinais de eletroencefalograma (EEG) e eletromiografia(EMG), imagens de ressonância magnética (MRI), dados comportamentais, etc. Um componentepode ser usado em diferentes protocolos ou múltiplas vezes em um mesmo protocolo, com diferentesconfigurações.


Experimentos são projetados e conduzidos pelos pesquisadores, no contexto de estudos. Osestudos estão inseridos em projetos de pesquisa e são financiados por agências financiadoras. Umprojeto de pesquisa pode ser classificado por uma área de pesquisa e apresenta palavras-chaves queo definem. Os pesquisadores das instituições são organizados em laboratórios de pesquisa. Umlaboratório é dirigido por um pesquisador e pode hospedar diversos projetos de pesquisa. Todosos projetos de pesquisa tem um coordenador, e geralmente grupos de pesquisadores que colaboramde diferentes instituições. Experimentos bem sucedidos têm seus resultados disseminados para acomunidade científica na forma de documentos como artigos, relatórios, padrões, etc.

6.3.2 Módulos de Dados, DBFD e Anotações

Os módulos de dados identificados a partir dos requisitos de dados representados na Seção 6.3.1 eseus respectivos modelos conceituais EER são mostrados nas Figuras 6.1 a 6.4. A Figura 6.1 mostraos três módulos de dados definidos para representar as informações básicas sobre experimentos eseus resultados: Experiment, Experiment Classification e Experiment Documentation.

Figura 6.1: Módulos de dados com informações básicas sobre experimentos.

Grupos de sujeitos dos experimentos são representados nos cinco módulos mostrados na Fi-gura 6.2: Group, SubjectOfGroup, Subject, Human e NonHuman.

Figura 6.2: Módulos de dados relacionados a grupos de sujeitos dos experimentos.

Os módulos de dados projetados para representar informações relacionados ao protocolo expe-rimental são retratados na Figura 6.3: Experimental Protocol, Block, Task, Questionnaire,Stimulus, Data Collection, Pause e Instruction. Note que cada tipo de componente do pro-tocolo experimental foi modelado como um módulo de dados diferente. Com isso, permite-se queum laboratório de pesquisa selecione apenas os tipos de componentes usados nos experimentos quenele são conduzidos.


Figura 6.3: Módulos de dados relacionados ao protocolo experimental.

Para a estrutura organizacional, três módulos de dados foram definidos – Institution,Research Laboratory e Research Project – mostrados na Figura 6.4.

Figura 6.4: Módulos de dados da estrutura organizacional dos projetos de pesquisa.

A partir dos módulos de dados acima, o DBFD apresentado na Figura 6.5 foi criado.

Figura 6.5: Diagrama de Características de Banco de Dados para o estudo de caso.

No DBFD do estudo de caso (Figura 6.5), Experiment, Subject, Group, ExperimentalProtocol, e Block são denotados como módulos base. Esses módulos de dados vão ser partede todos os esquemas conceituais de banco de dados derivados a partir do DBFD.

É importante notar que parte dos requisitos de dados descritos na Seção 6.3.1 não são direta-mente representados nos módulos de dados, mas sim nas relações entre os módulos definidas no


DBFD da Figura 6.5, e melhor detalhados por meio de anotações. Como exemplo, considere osseguintes requisitos de dados: “um experimento é composto de grupos”, “um grupo é compostode sujeitos”, “sujeitos podem ser humanos ou não humanos”. Todos esses requisitos se referem a“ligações” que devem ser estabelecidas entre tipos de entidades pertencentes a diferentes módulos.

As anotações para o estudo de caso estão listadas a seguir. As anotações detalham em nívelde modelo EER as relações definidas no DBFD. Por exemplo, a relação R1, entre os módulos dedados Group e Subject, deve ser implementada como um relacionamento chamado is_composed_ofentre os tipos de entidade Group e Subject, com cardinalidade M:N e participação total:total.E as relações X1 e X2, a partir do módulo Subject para os módulos de dados NonHuman e Human,devem ser implementadas como uma especialização disjunta chamada subject_type a partir do tipode entidade Subject (superclasse) para os tipos de entidades NonHuman e Human (subclasses).

A1 : ADD RELATIONSHIP has BETWEEN (M Experiment - E Experiment) AND (M Group - E Group) 1:N PARTIAL:TOTAL;

A2 : ADD RELATIONSHIP follows BETWEEN (M Experiment - E Experiment) AND(M Paradigm - E Experiment Classification) M:N TOTAL:PARTIAL;

A3 : ADD RELATIONSHIP generates BETWEEN (M Experiment - E Experiment) AND(M Experiment Documentation - E Document) M:N PARTIAL:PARTIAL;

A4 : ADD RELATIONSHIP is_responsible_for BETWEEN (M Institution - E Person) AND(M Experiment - E Experiment) M:N PARTIAL:PARTIAL;

A5 : ADD RELATIONSHIP promotes BETWEEN (M ResearchProject - E ResearchProject) AND(M Study - E Study) M:N PARTIAL:TOTAL;

A6: ADD RELATIONSHIP participates BETWEEN (M Institution - E Person) AND(M Study - E Study) M:N PARTIAL:TOTAL;

A7 : ADD RELATIONSHIP has BETWEEN (M Institution - E Institution) AND(M ResearchProject - E ResearchProject) M:N PARTIAL:TOTAL;

A7: ADD RELATIONSHIP colaborates_to BETWEEN (M Institution - E Person) AND(M ResearchProject - E ResearchProject) M:N TOTAL:TOTAL ATTR=is_coordinator?;

A8 : ADD RELATIONSHIP happens_at BETWEEN (M Research Project - E ResearchProject) AND(M ResearchLaboratory - E ResearchLaboratory) M:N PARTIAL:PARTIAL ATTR=start_date, end_date;

A9 : ALTER (M ResearchLaboratory - E ResearchLaboratory) DROP ATTRIBUTE name, address, phone, website;

A10 : ALTER (M Group - R is_composed_of) ADD ATTRIBUTE consent_form;

A11 : ADD RELATIONSHIP has_experimental_protocol BETWEEN (M Group - E Group) AND(M ExperimentalProtocol - E ComponentConfiguration) 1:1 TOTAL:TOTAL;

A12 : ADD SPECIALIZATION component_type FROM SUPERCLASS (M ExperimentalProtocol - E Component)TO SUBCLASS (M Block - E Block) DISJOINT;

A12 : ADD RELATIONSHIP sets_up_component_of_block BETWEEN (M ExperimentalProtocol -E ComponentConfiguration) AND (M Block - E Block) N:1 TOTAL:TOTAL ATTR=order;

R1 : ADD RELATIONSHIP is_composed_of BETWEEN (M Group - E Group) AND(M Subject - E Subject) M:N TOTAL:TOTAL;

R2 : ADD RELATIONSHIP performs BETWEEN (M Study - E Study) AND(M Experiment - E Experiment) 1:N TOTAL:TOTAL;

R4 : ADD RELATIONSHIP contains BETWEEN (M Institution - E Institution) AND(M ResearchLaboratory - E ResearchLaboratory) 1:N PARTIAL:TOTAL;

R4 : ADD RELATIONSHIP is_member_of BETWEEN (M Institution - E Person) AND(M ResearchLaboratory - E ResearchLaboratory) N:1 PARTIAL:TOTAL ATTR=is_director?;

O1: ADD SPECIALIZATION component_type FROM SUPERCLASS (M ExperimentalProtocol - E Component)TO SUBCLASS (M Questionnaire - E Questionnaire) DISJOINT;

O2: ADD SPECIALIZATION component_type FROM SUPERCLASS (M ExperimentalProtocol - E Component)TO SUBCLASS (M Stimulus - E Stimulus) DISJOINT;

O3: ADD SPECIALIZATION component_type FROM SUPERCLASS (M ExperimentalProtocol - E Component)TO SUBCLASS (M Task - E Task) DISJOINT;

O4: ADD SPECIALIZATION component_type FROM SUPERCLASS (M ExperimentalProtocol - E Component)TO SUBCLASS (M Pause - E Pause) DISJOINT;


O5: ADD SPECIALIZATION component_type FROM SUPERCLASS (M ExperimentalProtocol - E Component)TO SUBCLASS (M Instruction - E Instruction) DISJOINT;

O6: ADD SPECIALIZATION component_type FROM SUPERCLASS (M ExperimentalProtocol - E Component)TO SUBCLASS (M Data Collection - E DataCollection) DISJOINT;

X1 : ADD SPECIALIZATION subject_type FROM SUPERCLASS (M Subject - E Subject)TO SUBCLASS (M NonHuman - E NonHuman) DISJOINT;

X2 : ADD SPECIALIZATION subject_type FROM SUPERCLASS (M Subject - E Subject)TO SUBCLASS (M Human - E Human) DISJOINT;

O esquema conceitual EER apresentado na Figura 6.6 é o resultado quando os módulos dedados base e os módulos Research Project, Study, HumanGroup, Human, Task, Instruction eData Collection são selecionados no DBFD da Figura 6.5.

Figura 6.6: Um esquema conceitual de banco de dados derivado do DBFD da Figura 6.5.

Capítulo 7

Planejamento

7.1 Atividades e Cronograma

As seguintes atividades estão previstas para a continuidade deste projeto de mestrado:

1. Revisão bibliográfica – essa atividade corresponde ao estudo dos métodos, técnicas e fer-ramentas que serão utilizadas neste projeto, bem como dos trabalhos relacionados a ele. Emparticular, o estudo focará em: engenharia de domínio, modelagem conceitual e física de bancode dados, e iniciativas para a representação e armazenamento de dados em neurociência.

2. Continuação do estudo de caso – essa atividade consiste em dar continuidade ao estudode caso que está sendo realizado dentro do domínio de neurociência. Ela pode ser divididaem três atividades:

(a) Levantamento de requisitos de dados – nessa atividade serão realizadas visitas aos labora-tórios associados ao NeuroMat, para o acompanhamento da realização de experimentos epara entrevistas com os cientistas envolvidos, com o objetivo de levantar novos requisitosde dados relacionados às coletas de dados dos experimentos.

(b) Definição de esquemas conceituais para novos módulos de dados – nessa atividade serãocriados esquemas conceituais para os novos módulos de dados que possam surgir a partirda Atividade 2a.

(c) Atualização do diagrama de características de banco de dados – nessa atividade seráatualizado o diagrama de características de dados do estudo de caso a partir dos novosmódulos de dados da Atividade 2b.

3. Desenvolvimento da ferramenta de software – nessa atividade será criada uma ferra-menta de software para amparar o uso da técnica de modelagem proposta no trabalho. Aferramenta de software conterá basicamente três funcionalidades:

(a) Criação e edição de um diagrama de características de dados, com a possibilidade deeditar os modelos conceituais que estão contidos nos módulos de dados.

(b) Mecanismo para geração automática de modelos de implementação a partir dos modelosconceituais derivados de diagramas de características de dados.

(c) Mecanismo para conversão automática de esquemas de implementação em comandosDDL na linguagem SQL, para a criação ou modificação de bancos de dados.

4. Criação da notação – nessa atividade será criada uma notação, ou uma linguagem demodelagem de domínio específico, que possibilitará que neurocientistas estendam a família deesquemas criada a partir do estudo de caso da Atividade 2, adicionando a ela a capacidadede representar novos tipos de experimentos sempre que necessário.

33

34 CAPÍTULO 7. PLANEJAMENTO

5. Teste, validação e avaliação dos resultados – essa atividade consiste na avaliação dacorreção e da qualidade dos resultados obtidos na aplicação da proposta, por meio de testescontrolados e estudos de casos envolvendo os cientistas do projeto NeuroMat e os experimentosem neurociência que eles rotineiramente realizam.

6. Escrita de artigos científicos para a divulgação dos resultados – o objetivo principaldessa atividade é a publicação dos resultados obtidos no projeto em congressos e revistascientíficas dos domínios de bancos de dados, neurociência (em particular, neurociência com-putacional) e e-science.

Dentre os veículos de divulgação científica nos quais os resultados deste trabalho poderiamser publicados, é possível destacar:

Conferências

• Simpósio Brasileiro de Banco de Dados;

• International Conference on Conceptual Modeling ;

• The INCF Neuroinformatics Congress;

• The IEEE International Conference on e-Science.

Periódicos

• Journal of Information and Data Management (SBC, ISSN:2178-7107);

• Neuroinformatics (Springer, ISSN: 1559-0089);

• Journal of Computational Neuroscience (Springer, ISSN: 1573-6873).

7. Escrita da dissertação – essa atividade consiste na confecção da dissertação de mestradoda aluna, requisito final para a obtenção do título de mestre pelo IME-USP.

A Tabela 7.1 apresenta o cronograma das atividades previstas.

Tabela 7.1: Cronograma de execução

Atividades 2015 2016Jul Ago Set Out Nov Dez Jan Fev Mar Abr Mai Jun

Atividade 1 X X X X X X X X X X X XAtividade 2 X X X X XAtividade 3 X X X X X XAtividade 4 X X XAtividade 5 X X X XAtividade 6 X X X X X XAtividade 7 X X X X X X

7.2 Comentários Adicionais

Todos os créditos em disciplinas necessários para o depósito da dissertação já foram concluídos.

Apêndice A

O centro de Pesquisa, Inovação e Difusãoem Neuromatemática

O Centro de Pesquisa, Inovação e Difusão em Neuromatemática (NeuroMat) [neu] tem comoprincipal objetivo integrar modelagem matemática com pesquisa básica e aplicada na fronteira daneurociência. Os laboratórios de pesquisa em neurociência geram volumes cada vez maiores dedados. A análise desses dados depende da criação de novos modelos matemáticos e ferramentascomputacionais de apoio. A proposta do NeuroMat vai de encontro a essa necessidade, desenvol-vendo modelos teóricos – para explicar os fatos experimentais e sugerindo predições que possam sertestadas – e ferramentas de software para gerenciamento e análise de dados.

Do NeuroMat participam diversos laboratórios de pesquisa em neurociência que coletam dadosa partir de diferentes tipos de experimentos de eletrofisiologia e neuroimagem, envolvendo tantohumanos, quanto outros tipos de animais. Matemáticos, estatísticos e cientistas da computação, doIME-USP e de outras instituições brasileiras e estrangeiras associadas ao projeto, estão trabalhandoem colaboração com os neurocientistas na construção desses modelos matemáticos e ferramentas desoftware.

Um dos objetivos iniciais do NeuroMat no que tange transferência de tecnologia e inovação édefinir soluções computacionais para: (i) gerenciar os dados produzidos no projeto; (ii) facilitar ainteração entre os pesquisadores envolvidos no projeto; (iii) disponibilizar publicamente os produtosdo projeto. A base para essas soluções é a criação de um banco de dados para o Neuromat e,posteriormente, de um portal web que exercerá a função de science gateway, atuando como umainterface pública de acesso a esse banco de dados e um canal de comunicação entre os pesquisadoresno projeto.

35

36 APÊNDICE A

Referências Bibliográficas

[ABG13] Alvin Ahnassay, Ebrahim Bagheri e Dragan Gasevic. Empirical evaluation in soft-ware product line engineering. Relatório Técnico TR-LS3-130084R4T, Laboratory forSystems, Software and Semantics, Ryerson University, 2013. 18

[AR07] Elena Alana e Ana Isabel Rodríguez. Domain engineering methodologies survey. Rela-tório técnico, 2007. 12

[AZDT11] Lamia Abo Zaid e Olga De Troyer. Towards modeling data variability in softwareproduct lines. Em Terry Halpin, Selmin Nurcan, John Krogstie, Pnina Soffer, Erik Pro-per, Rainer Schmidt e Ilia Bider, editors, Enterprise, Business-Process and InformationSystems Modeling, volume 81 of Lecture Notes in Business Information Processing,páginas 453–467. Springer Berlin Heidelberg, 2011. 16

[BFK+99] Joachim Bayer, Oliver Flege, Peter Knauber, Roland Laqua, Dirk Muthig, Klaus Sch-mid, Tanya Widen e Jean-Marc DeBaud. Pulse: A methodology to develop softwareproduct lines. Em Proceedings of the 1999 Symposium on Software Reusability, SSR’99, páginas 122–131, New York, NY, USA, 1999. ACM. 14

[BHST04] Yves Bontemps, Patrick Heymans, Pierre-Yves Schobbens e Jean-Christophe Trigaux.Semantics of foda feature diagrams. Em Proceedings SPLC 2004 Workshop on SoftwareVariability Management for Product Derivation – Towards Tool Support, páginas 48–58, 2004. 13

[BOR09] Joerg Bartholdt, Roy Oberhauser e Andreas Rytina. Addressing data model variabilityand data integration within software product lines. International Journal On Advancesin Software, 2(1):84–100, 2009. 16

[BSRC] David Benavides, Sergio Segura e Antonio Ruiz-Cortes. Automated analysis of fea-ture models 20 years later: A literature review. http://www.lsi.us.es/~dbc/en/?Research. Acesso em: 12/06/2015. vii, 13

[Cam12] Carlos Camacho. Software product lines using foda: A formal approach. Dissertaçãode Mestrado, Universidad Complutense de Madrid, Madrid, Spain, 2012. 11

[Car] Code Analysis, Repository & Modelling for e-Neuroscience (CARMEN) homepage.http://www.carmen.org.uk/. Acesso em: 12/06/2015. 26

[CB11] Lianping Chen e Muhammad Ali Babar. A systematic review of evaluation of vari-ability management approaches in software product lines. Information and SoftwareTechnology, 53(4):344–362, 2011. 12, 18

[CN01] Paul Clements e Linda Northrop. Software Product Lines: Practices and Patterns.Addison-Wesley Longman Publishing Co., Inc., 2001. 12

[EN10] Ramez Elmasri e Shamkant Navathe. Fundamentals of Database Systems. Addison-Wesley Publishing Company, 6th edição, 2010. vii, 5, 7, 8, 9, 10, 23

37

http://www.lsi.us.es/~dbc/en/?Research

http://www.lsi.us.es/~dbc/en/?Research

http://www.carmen.org.uk/

38 REFERÊNCIAS BIBLIOGRÁFICAS

[FSM+11] Gwen Frishkoff, Jason Sydes, Kurt Mueller, Robert Frank, Tim Curran, John Connolly,Kerry Kilborn, Dennis Molfese, Charles Perfetti e Allen Malony. Minimal informationfor neural electromagnetic ontologies (MINEMO): A standards-compliant method foranalysis and integration of event-related potentials (ERP) data. Standards in GenomicSciences, 5(2):211–223, 2011. 27

[GFd98] Martin L Griss, John Favaro e Massimo d’Alessandro. Integrating feature modelingwith the rseb. Em Software Reuse, 1998. Proceedings. Fifth International Conferenceon, páginas 76–85. IEEE, 1998. 13

[Gom04] Hassan Gomaa. Designing Software Product Lines with UML: From Use Cases toPattern-Based Software Architectures. Addison Wesley Longman Publishing Co., Inc.,2004. 12

[GOS+09] Frank Gibson, Paul G Overton, Tom V Smulders, Simon R Schultz, Stephen J Eglen,D Ingram, Stefano Panzeri, Phil Bream, Evelyne Sernagor, Mark Cunningham, Chris-toph Echtermeyer, Jennifer Simonotto, Marcus Kaiser, Daniel C Swan e Phillip Lord.Minimum information about a neuroscience investigation (MINI): electrophysiology.Nature Precedings, 2009. 27

[Har02] M. Harsu. A survey on domain engineering. Relatório Técnico 31, Institute of SoftwareSystems, Tampere University of Technology, 2002. 12, 13

[HCMD92] Jean-luc Hainaut, Mario Cadelli, Olivier Marchand e Bernard Decuyper. Databasecase tool architecture : Principles for flexible design strategies. Em Proc. of the 4thInt. Conf. on Advanced Information System Engineering (CAiSE-92), páginas 187–207.Springer-Verlag, 1992. 15

[JGJ97] Ivar Jacobson, Martin Griss e Patrik Jonsson. Software reuse architecture, process, andorganization for business success. Em Computer Systems and Software Engineering,1997., Proceedings of the Eighth Israeli Conference on, páginas 86–89. IEEE, 1997. 13

[JP05] A. Jedlitschka e D. Pfahl. Reporting guidelines for controlled experiments in softwareengineering. Em 2005 International Symposium on Empirical Software Engineering,páginas 1–10. IEEE, 2005. 19

[KCH+90] Kyo C. Kang, Sholom G. Cohen, James A. Hess, William E. Novak e A. SpencerPeterson. A feature-oriented domain analysis (foda) feasibility study. Relatório TécnicoCMU/SEI-90-TR-21, Software Engineering Institute, Pittsburgh, Pennsylvania, 1990.12

[KK13] Niloofar Khedri e Ramtin Khosravi. Handling database schema variability in softwareproduct lines. Em Proceedings of the 2013 20th Asia-Pacific Software EngineeringConference (APSEC) - Volume 01, APSEC ’13, páginas 331–338, Washington, DC,USA, 2013. IEEE Computer Society. 16

[KKL+98] Kyo C. Kang, Sajoong Kim, Jaejoon Lee, Kijoo Kim, Euiseob Shin e Moonhang Huh.FORM: A feature-oriented reuse method with domain-specific reference architectures.Annals of Software Engineering, 5:143–168, 1998. 12, 13

[Köt01] R Kötter. Neuroscience databases: tools for exploring brain structure–function relati-onships. Philosophical Transactions of the Royal Society of London. Series B: BiologicalSciences, 356:1111–1120, 2001. 26

[LCC94] Chien-Tsai Liu, Panos K. Chrysanthis e Shi-Kuo Chang. Database schema evolutionthrough the specification and maintenance of changes on entities and relationships.Em Entity-Relationship Approach - ER’94, Business Modelling and Re-Engineering,

REFERÊNCIAS BIBLIOGRÁFICAS 39

13th International Conference on the Entity-Relationship Approach, páginas 13–16.Springer, 1994. 15

[Nem] Neural ElectroMagnetic Ontologies (NEMO) homepage. http://nemo.nic.uoregon.edu/. Acesso em: 12/06/2015. 26

[neu] Centro de Pesquisa, Inovação e Difusão em Neuromatemática (NeuroMat) homepage.http://neuromat.numec.prp.usp.br/. Acesso em: 12/06/2015. 35

[PFH+08] Russell A Poldrack, Paul C Fletcher, Richard N Henson, Keith J Worsley, MatthewBrett e Thomas E Nichols. Guidelines for reporting an fMRI study. Neuroimage,40(2):409–414, 2008. 25

[Pro97] H.A. Proper. Data schema design as a schema evolution process, 1997. 15

[RCR93] John F. Roddick, Noel G. Craske e Thomas J. Richards. A taxonomy for schemaversioning based on the relational and entity relationship models. Em LECTURENOTES IN COMPUTER SCIENCE, páginas 139–150. Springer-Verlag, 1993. 15

[RH09] Per Runeson e Martin Höst. Guidelines for conducting and reporting case study researchin software engineering. Empirical Software Engineering, 14(2):131–164, 2009. 19

[RJB99] James Rumbaugh, Ivar Jacobson e Grady Booch, editors. The Unified ModelingLanguage Reference Manual. Addison-Wesley Longman Ltd., Essex, UK, UK, 1999.13

[SCK+96] Mark Simos, Dick Creps, Carol Klingler, Larry Levine e Dean Allemang. Or-ganization domain modeling (odm) guidebook, version 2.0. Relatório TécnicoSTARS–VC–A025/001/00, Lockheed Martin Tactical Defence Systems, 1996. 14

[Seg] Sergio Segura. A feature diagram representing a configurable e-shop system. http://en.wikipedia.org/wiki/Feature_model. Acesso em: 12/06/2015. vii, 22

[SKR+09] Norbert Siegmund, Christian Kästner, Marko Rosenmüller, Florian Heidenreich, SvenApel e Gunter Saake. Bridging the gap between variability in client application anddatabase schema, 2009. 16

[TFS+08] Chris F Taylor, Dawn Field, Susanna-Assunta Sansone, Jan Aerts, Rolf Apweiler, Mi-chael Ashburner, Catherine A Ball, Pierre-Alain Binz, Molly Bogue, Tim Booth et al.Promoting coherent minimum reporting guidelines for biological and biomedical inves-tigations: the MIBBI project. Nature Biotechnology, 26(8):889–896, 2008. 27

[TLNJ11] Toby J. Teorey, Sam S. Lightstone, Tom Nadeau e H. V. Jagadish. Database Modelingand Design: Logical Design. Morgan Kaufmann Publishers Inc., San Francisco, CA,USA, 5th edição, 2011. 5, 10

[VDLP05] Frank Van Der Linden e Klaus Pohl. Software Product Line Engineering: Foundations,Principles, and Techniques. Springer-Verlag New York, Inc., 2005. 11, 18

[wik] List of neuroscience databases. http://en.wikipedia.org/wiki/List_of_neuroscience_databases. Acesso em: 12/06/2015. 26

[WL99] David M. Weiss e Chi Tau Robert Lai. Software product-line engineering: a family-based software development process. 1999. 14

http://nemo.nic.uoregon.edu/

http://nemo.nic.uoregon.edu/

http://neuromat.numec.prp.usp.br/

http://en.wikipedia.org/wiki/Feature_model

http://en.wikipedia.org/wiki/Feature_model

http://en.wikipedia.org/wiki/List_of_neuroscience_databases

http://en.wikipedia.org/wiki/List_of_neuroscience_databases

Larissa Cristina Moraes Qualificação de mestrado Instituto...

Documents

Transcript of Larissa Cristina Moraes Qualificação de mestrado Instituto...