Sintaxe Concreta

A partir da Análise de Domínio realizada na secção §4.1, foi definida uma notação própria, baseada em ícones, que representa os conceitos e relacionamentos com um significado associado. Na figura20, são exibidas as representações do objeto Relation e Attribute. A Relation é representada por um caixa retangular, em cujo topo são incluídos um ícone e o nome da relação. A caixa é constituída por dois compartimentos divididos em Attribute e Constraints: o primeiro compartimento é composto de todos os atributos da relação, o nome e o tipo de dados ou domínio do atributo, sendo possível identificar, através da representação gráfica, se o atributo permite valor nulo ou não, caso não permita valor nulo, o atributo ficará em negrito; no segundo compartimento

mais adiante neste capítulo.

Figura 20 – Relation e Attribute

Fonte: Próprio autor

Na figura21são exibidas as representações das constraints Primary Key, Unique Key,

Checke Trigger. A Primary Key está representada no compartimento inferior da Relation através de um identificador (PK) seguido do seu nome, conforme a figura21(a). Na definição de uma

Primary Key, são escolhidos os atributos que a compõem, e a sintaxe concreta que representa os atributos que fazem parte da Primary Key é apresentada ao lado direito do atributo, colocando o identificador (PK) entre parênteses. Esses atributos ficarão em negrito, pois, não permitem valor nulo. Na figura21(b), é exibida a representação gráfica para o objeto Unique Key. Este possui o identificador AKn, em que n é um número inteiro para identificar, de forma exclusiva, a constraint, ou seja, como uma relação pode conter mais de um objeto desse tipo, o número inteiro serve para identificar a chave única na relação. Logo após o identificador, é mostrado o nome da chave única. Na definição da Unique Key são escolhidos os atributos que a compõem, por sua vez, a sintaxe concreta que representa essa informação é apresentada ao lado direito do atributo, colocando o identificador (AKn) entre parênteses. As representações gráficas para os objetos Check e Trigger são semelhantes e apresentadas na figura21(c). Estas possuem o identificador CKn, para Check e TGn, para Trigger, onde n é um número inteiro que identifica de forma exclusiva, a constraint na relação. Logo após o identificador, é mostrado o nome destes objetos.

Na figura22, são apresentadas as representações gráficas para os objetos Assertion e

Domain. Uma Assertion é representada por uma caixa com os cantos arredondados, possuindo no topo o ícone e nome da Assertion. O domain, por sua vez, é representado por uma caixa retangular que também possui no topo o ícone e o nome do domain. O domain possui um compartimento onde são agrupadas as constraints do tipo Check, que respeitam as mesmas regras de identificação mostradas na figura21(c).

As ligações entre as relações, representado o conceito de chave estrangeira (ForeignKey), são especificadas através de setas e linhas. As setas podem ser representadas de duas formas: seta aberta, apontará para a relação referenciada, e/ou seta fechada, utilizada para indicar que os valores da relação referenciada são únicos na relação que referencia. As linhas de ligação estabelecidas entre duas relações também podem ser representadas de duas formas: linha continua, que indica que os atributos da ForeingKey são obrigatórios na relação que referencia; ou linha

(a) Constraint PrimaryKey

(b) Constraint UniqueKey

(c) Constraints Trigger e Check

Figura 21 – Sintaxe concreta das Constraints

Fonte: Próprio autor

Figura 22 – Assertion e Domain

Fonte: Próprio autor

pontilhada, que indica que os valores desses atributos podem assumir ser nulos. A figura 23

exemplifica as formas de ligações entre as relações.

A identificação das ligações é feita através de um texto localizado na ligação entre as relações conforme exemplificado na figura24. O texto é iniciado pelo identificador da ForeignKey e seguido, entre parênteses, das opções para violações de restrições de integridade. O identificador da ForeignKey será no formato FKn, em que n é um número inteiro para identificar de forma exclusiva, a FK na relação. As violações de restrições de integridade são causadas por operações de atualização, representadas no texto pela letra U (update), e de exclusão, representadas no texto pela letra D (delete). Logo após cada tipo de operação de violação de restrição virá, entre chaves, o tipo de tratamento que será executado, representando pelas letras 1) R, para RESTRICT ; 2) C,

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

Fonte: Próprio autor

para CASCADE; 3) N, para NULL e 4) D, para DEFAULT.

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

Fonte: Próprio autor

4.3

Sintaxe Abstrata

O metamodeloRMMé a sintaxe abstrata que descreve os conceitos da linguagem proposta e as relações válidas que podem ser realizadas. ORMMconsiste em um metamodelo que: 1) é baseado nos conceitos do Modelo Relacional, apresentados na secção §2.1; 2) é especificado utilizando o meta-metamodelo ECore; 3) serve como metamodelo base para ferramentas CASE que visam a construção de um projeto lógico de um BD, segundo o Modelo Relacional; 4) possibilita, através das restrições Object Constraint Language (OCL), a verificação da consistência dos esquemas desenvolvidos e, finalmente, 5) é definido para possibilitar a compatibilidade com as diversas soluções deBDs existentes, pois é baseado no SQL ANSI 2003 que é um padrão internacional da linguagemSQL, adotado pela International Organization for Standardization (ISO). A seguir, será apresentado, em fragmentos, o metamodelo RMM, em que os objetos apresentados na cor verde são enumerações, as metaclasses apresentadas na cor amarela são as representações de classes concretas e na cor cinza, são metaclasses abstratas que não possuem representação na sintaxe concreta.

Na figura25, apresenta-se a metaclasse Schema e suas relações. A metaclasse Schema é o elemento raiz do metamodelo proposto e é composto de uma coleção de objetos tais como

Figura 25 –RMM- Schema, Domain, Relation e SchemaConstraint

Fonte: Próprio autor

de zero ou mais SchemaConstraint, Domain e Relation. Para detalhar essas metaclasses serão necessários o entendimento de outras metaclasses que estão representadas na figura26, figura27

e figura28.

Figura 26 –RMM- Constraints

metaclasse Constraint é especializada em duas outras metaclasses: SchemaConstraint e a Relati-

onConstraint. A metaclasse SchemaConstraint é especializada na metaclasse Assertion, que por sua vez, não tem nenhum componente adicional, mas possui uma propriedade chamada condition para que o usuário possa especificar a expressão condicional que será checada pela restrição. Já a metaclasse RelationConstraint é especializada em cinco outras metaclasses: PrimaryKey,

UniqueKey, ForeignKey, Checke Trigger. A metaclasse RelationConstraint foi criada com uma associação à metaclasse Attribute, isto para possibilitar que as restrições de relação possam ser associadas a um ou mais atributos da relação. Além disso, nesta metaclasse, também foi criada uma propriedade label para rotular os objetos especializados facilitando sua identificação, con- forme descrito na secção §4.2. As metaclasses PrimaryKey e UniqueKey não possuem nenhuma propriedade adicional, conforme pode ser verificado na figura26. Já a metaclasse ForeignKey possui as propriedades onUpdate e onDelete, que servem para especificar o tipo de tratamento, caso aconteça violação de integridade nas operações de atualização e exclusão. Também para a

ForeignKeyfoi definida a propriedade isNotNull, para indicar se os atributos da chave estrangeira são nulos ou não na relação filha. Além disso, também foi criada a propriedade isUnique, para indicar se os atributos da chave estrangeira são unicamente identificados ou não na relação filha. A metaclasse ForeignKey ainda tem como propósito realizar a ligação entre as relações através de uma associação composta por origem e destino, representada pelas propriedades source e target, respectivamente. A metaclasse Trigger possui propriedades que são utilizadas para especificar a construção do trigger. As propriedades insert, update, delete são do tipo booleano e indicam se estes eventos serão disparadores do trigger. Assim, um trigger irá contemplar em sua definição todos os eventos que forem definidos com valor true. A propriedade actionTime indica o tempo de ação do disparador e pode ser do tipo AFTER, BEFORE e INSTEAD OF, conforme visualizado na enumeração ActionTimeType da figura26. A condition é uma propriedade criada para definir uma expressão lógica que é avaliada antes do disparo da trigger. A propriedade statementSQL é o código SQLque será utilizado no corpo da trigger. A propriedade actionGranularity é o nível de granularidade que pode ser STATEMENT, funciona uma vez para todo o evento da

trigger, e ROW, é executada de acordo com o número de linhas afetadas. As propriedades oldRow,

newRow, oldTable e newTable são usadas para indicar o alias para as tabelas OLD e NEW, criadas internamente pelas soluções deBDpara representar os valores antes da solicitação da operação e os novos valores enviados para a operação.

Na figura27, são aprestadas a metaclasse Domain e seus elementos relacionados. O domí- nio possui as propriedades name e description, para sua identificação, defaultValue, para indicar se o domínio possui um valor padrão, e dataType, para informar se o valor dessa propriedade é um dos tipos básicos representados na enumeração BaseType. A metaclasse domain ainda possui uma associação com uma RelationConstraint do tipo Check, para indicar se o domínio tem alguma restrição de valor.

Figura 27 –RMM- Domain

Fonte: Próprio autor

metaclasse Relation possui dois compartimentos: attributes, que é uma coleção de um ou mais elementos do tipo Attribute, e relationConstraints, que é uma coleção de um ou mais elementos do tipo RelationConstraint. A metaclasse Attribute possui as propriedades: name e description, para sua identificação; defaultValue, para indiciar o valor padrão; dataType, cujo valor dessa propriedade é um dos tipos básicos representados na enumeração BaseType; size, para informar o tamanho máximo; isNotNull, para indicar se o atributo permite valor nulo ou não. A metaclasse

Attributepossui ainda uma associação com a metaclasse Domain, quando o usuário especifica o domínio de um atributo, o mesmo terá as mesmas configurações fornecidas na especificação do domínio.

Na figura29, apresenta-se o metamodeloRMM completo, agrupando os fragmentos apresentados anteriormente. O relacionamento, a cardinalidade e as especializações exibidas nesta figura fazem referência ao domínio detalhado, identificado pela metodologia FODA (conforme secção §4.1deste trabalho). Neste metamodelo, é possível identificar como cada componente é formado e em qual componente pode-se fazer uso dos elementos declarados.

4.4

Semântica Estática

Com a Semântica Estática pode-se especificar um conjunto de restrições para validar os modelos e impedir a ocorrência de erros semânticos no esquema relacional a partir doRMM. As regras de restrições são definidas, pois podem existir combinações no modelo que mesmo sendo

Figura 28 –RMM- Relation

Fonte: Próprio autor

sintaticamente válidas, por razões de semântica estática, causam erros no modelo e devem ser impedidas. Sempre que uma construção possuir erros, um símbolo vermelho é mostrado ao lado do objeto, bem como a respectiva mensagem de erro é apresentada na seção de propriedades, como pode ser visualizado na figura30. Assim sendo, foram construídas 20 regras básicas em

OCLe em linguagem Java com o uso do frameworkGMF. Essas regras foram para os seguintes elementos do metamodelo: Attribute, Relation, Domain, Assertion, Trigger, Primary Key, Foreign

Key, Unique Key e Check. Estas regras podem ser apresentadas a seguir:

• Attribute

1. Verificar se o nome do atributo foi definido. O nome é uma característica obrigatória em um atributo.

• Relation

1. Verificar se o nome da relação foi definido. O nome é uma característica obrigatória em uma relação.

2. Verificar se foram definidos atributos para uma Relação. Uma relação deve ser com- posta de um ou mais atributos.

3. Verificar se foi definida uma chave primária para uma relação. A chave primária de uma relação é obrigatória, pois o modelo relacional exige que cada linha da relação seja única, e as chaves primárias são utilizadas para identificar unicamente as linhas da relação.

F igura 29 – Metamodelo RMM F onte: Própr io autor

(a) Visualização do erro em um objeto

(b) Mensagem de erro na seção propriedades

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

Fonte: Próprio autor

4. Verificar se existe somente uma chave primária na relação. A chave primária é a melhor chave candidata para uma relação, ou seja, ela é única na relação.

5. O nome da relação deve ser único no esquema relacional.

• Domain

1. Verificar se o nome do domínio foi definido.

2. O nome do domínio deve ser único no esquema relacional. O nome de um domínio em esquema relacional deve ser único.

• Assertion

1. Verificar se o nome da asserção foi definido. O nome é uma característica obrigatória para identificar uma asserção.

2. O nome da asserção deve ser único no esquema relacional.

• Trigger

1. Verificar se o nome da trigger foi definido. O nome é uma característica obrigatória para identificar uma trigger.

1. Verificar se o nome da chave primária foi definido. O nome é uma característica obrigatória para identificar a chave primária.

2. Uma chave primária deve conter, pelo menos, um atributo. Uma chave é determinada com base no significado dos atributos, portanto é necessária a definição dos atributos que fazem parte da chave.

• Foreign Key

1. Verificar se o nome da chave estrangeira foi definido. O nome é uma característica obrigatória para identificar a chave estrangeira.

2. Uma chave estrangeira deve conter, pelo menos, um atributo. Uma chave é determinada com base no significado dos atributos, portanto, é necessária a definição dos atributos que fazem parte da chave.

3. A quantidade de atributos da chave estrangeira deve ser igual à quantidade de atributos da chave primária. Na definição da chave estrangeira, deve ser incluída a mesma quantidade de atributos da chave primária, à qual ela faz referência.

4. Os atributos da chave estrangeira devem ser do mesmo tipo dos atributos da chave primária. Na definição da chave estrangeira, devem ser incluídos atributos com o mesmo tipo da chave primária à qual ela faz referência.

• Unique Key

1. Verificar se o nome da chave única foi definido. O nome é uma característica obriga- tória para identificar a chave única.

2. Uma chave única deve conter pelo menos um atributo. Uma chave é determinada com base no significado dos atributos, portanto é necessária a definição dos atributos que fazem parte da chave.

• Check

1. Verificar se o nome do check foi definido. O nome é uma característica obrigatória para identificar um check.

4.5

Considerações Finais

Neste capítulo, foram apresentados os detalhes da construção da linguagem de modelagem para o projeto lógico. Esta linguagem foi especificada a partir da análise do domínio e da captura de requisitos, formando a base de conceitos para a construção dos seguintes elementos: sintaxe concreta (i.e, sintaxe gráfica), sintaxe abstrata (i.e., metamodelo) e semântica estática (formada por 20 regras de validação). A notação gráfica utilizada, o metamodelo e as regras de semântica

relacional de um projeto lógico de forma simples e clara.

Os elementos criados para a construção do metamodelo seguem a abordagem de desenvol- vimentoMDD, os quais são capazes de fornecer um alto nível de abstração no desenvolvimento de sistemas, pois utiliza modelos em todas as fases de desenvolvimento. Com os elementos propostos neste capítulo, torna-se possível a criação de esquemas lógicos, incluindo os conceitos do modelo relacional, apresentados na secção §2.1. Para mostrar a viabilidade de uso do meta- modelo proposto e seus elementos, no próximo capítulo é apresentada uma ferramentaCASE

5 FERRAMENTA RMMCASE

Neste capítulo, apresenta-se a ferramenta RMMCASE, desenvolvida com o objetivo de dar suporte aos elementos propostos nocapítulo 4. Serão exibidos exemplos de uso criados através desta ferramenta com o objetivo de mostrar a expressividade dos elementos do metamodelo, da notação gráfica e da validação semântica do projeto lógico. Na sequência, serão apresentados os recursos adicionais da ferramenta para gerar esquema em notação textual, transformar o esquema relacional em linguagemSQLe criar um projeto lógico a partir de umBDexistente. Por fim, será realizada uma análise comparativa com os trabalhos relacionados.