in1008 – projeto conceitual de bd

CIn/UFPE – IN1008 – PCBD - Prof. Robson Fidalgo UML for Design and Modeling 1


IN1008 – Projeto Conceitual de BD

UML for Design and Modeling

Desenho e Modelagem de dados usando UML

Por:

Erick Araújo [email protected]


• Motivação

• Objetivo

• Principais Conceitos Envolvidos

• Estado da Arte

• Abordagem Prática

• Referências

Roteiro


• Abstrair os modelos existentes e trabalhar sobre a meta-definição de modelos específicos permitem atender novos domínios de problemas;

• Mecanismos de extensibilidade e modularização são cada vez mais exigidos para atender domínios e dialetos tão dinâmicos e específicos;

• A histórico evolutivo da especificação UML procura criar mecanismos de extensibilidade para atender requisitos de domínios específicos;

• Por que não explorar as capacidades introduzidas na UML, com o uso de perfis (profiles), para atendimento das necessidades de modelagem de dados;

Motivação


Roteiro

• Motivação

• Objetivo


• Estado da Arte


• Referências


• Apresentar o contexto evolutivo da UML;

• Apresentar a arquitetura da UML;

• Apresentar a UML e suas capacidades;

• Metamodelos e Perfis no contexto da UML;

• Apresentar o Perfil UML voltado à modelagem de dados;

• Apresentar uma proposta de mapeamento Conceitual x Lógico;

• Apresentar uma ferramenta de modelagem adaptada o Perfil UML para modelagem de dados.

Objetivos


Roteiro

• Motivação

• Objetivo

• Conceitos Envolvidos

• Estado da Arte


• Referências


Principais conceitos envolvidos [1][5]

• MetaModelagem – técnica de criação de metamodelos.

• Modelagem – arte e ciência de criar modelos de uma determinada realidade.

• MetaModelo - modelos que descrevem artefatos e as regras para um modelo.

• Modelo – consiste na interpretação de um dado domínio do problema (fragmento do mundo real sobre o qual as tarefas de modelagem incidem).

• Esquema – especificação de um modelo usando uma determinada linguagem, formal ou informal, textual ou gráfica.

• Diagrama – representação gráfica do esquema.


Contexto Evolutivo - UML

• UML (Unified Modeling Language);• Resulta da unificação de diversas notações;

As três mais populares são:• Método OMT – Object Modeling Technique (James Rumbaugh,

1991)• Método Booch – (Grady Booch, 1991)• Método OOSE – Object-Oriented Software Engineering (Ivar

Jacobson, 1992)

• Combina técnicas como: Conceitos de modelagem de dados Modelagem de Negócio Modelagem de Objetos Modelagem de Componentes



• Outras contribuições [4]:



• Evolução [1][3]:

Resultado do trabalho de Booch e Rumbaugh em 1995.

Resultado da colaboração entre os três modelos

União com Ivar JacobsonObjectory + Rational Software Corp.

UML 1.0 como resultado da RFP proposta pela OMG, que gerou o consórcio UML Paterns (HP, IBM, ORACLE, etc.).

Outro grupo desenvolveu outra especificação em paralelo e acabou se unindo ao primeiro para formar a UML 1.1


UML – Objetivos

• Objetivos estabelecidos para UML [1]:

Permitir a modelagem de sistemas (não apenas software) usando conceitos OO;

Estabelecer acoplamento com artefatos conceituais e executáveis;

Resolver as questões de escala inerentes a sistemas complexos e de missão crítica;

Criar uma linguagem de modelagem utilizável por humanos e máquinas.


UML – Arquitetura

• Arquitetura de 4 níveis da OMG [1]:

Camada Descrição ExemploM3 Meta-metamodelo Define a linguagem para

especificar metamodelosMOF

MetaClass, MetaAttribute, MetaOperation

M2 Metamodelo Instância de um meta-metamodelo. Define a linguagem para especificar um modelo.

UML e CWM

Class, Property, Operation, Component

M1 Modelo Instância de um metamodelo, Define a linguagem para definir um domínio da informação.

Modelos de domínio específico.

Ex.: Modelo de locadora.

M0 Objeto do Usuário – dados do usuário

Instância de um modelo. Define os valores de um domínio específico.

Instâncias do modelo locadora, objetos.

Ex.: Locacao # 0123, DVD ...


UML – Arquitetura

• Arquitetura de 4 níveis da OMG [6][7]:


UML – Arquitetura

• UML 1.4 [6]:Três pacotes de alto nível

Núcleo para construções fundamentais do metamodelo da UML

Define um conjunto comum de tipos de dados válidos e enumerações para uso na definição do metamodelo da UML.

Meio de ajustar o uso para domínios de aplicações ou tecnologias específicas.


UML – Arquitetura

• UML 2.1.2 [7][8]:Pacotes do volume Infrastructure:

Metalinguagem CORE para reuso na definição de metamdelos, incluindo MOF, UML e CWM.

A especificação da UML 2.1.2 está organizada em dois volumes:

• Infrastructure

• Superstructure (próximo slide)

Criação de novas línguas baseado no mesmo core de metalinguagem como UML.

Pacotes do CORE:

Metamodelo no núcleo da arquitetura MDA.


UML – Arquitetura

• UML 2.1.2 [7][8]:

Pacotes de alto nível do pacote Superstructure:

Superstructure

• Estende e personaliza a Infrastructure para definir o metamodelo UML.

• Define os elementos que compõem as notações de modelagem da UML, criadas pela extensão e acréscimo dos elementos básicos definidos na Infrastructure.


UML – Arquitetura (Adicionais)

• OCL (Object Constraint Language)

Oferece semântica para declarar requisitos estáticos para atributos e operações;

Apenas adicionam restrições a elementos do modelo, não alteram o seu estado.


UML – Arquitetura (Adicionais)

• Action Semantics

Definem regras que controlam os aspectos dinâmicos de um sistema;

Podem ser usadas para definir implementações de método, para tratar chamadas e sinais entre objetos.


Roteiro

• Motivação

• Objetivo


• Estado da Arte


• Referências


UML – o que há de novo? [1]

UML 1.4 UML 2.0 MudançaDiagrama de Classes Diagrama de Classes IGUAL

Diagrama de Objetos Diagrama de Objetos Tratado no Diagrama Estrutura de Composição UML 2.0

Diagrama Objeto Composto Tratado no Diagrama Estrutura de Composição UML 2.0

Pacotes Diagrama de Pacotes A UML 1.4 não se referia a um diagrama de pacote, que era feito na tela do diagrama de classes.

Diagrama de Componentes Diagrama de Componentes IGUAL

Diagrama de Implantação Diagrama de Implantação IGUAL

Diagrama combinado de Implantação e componentes

Diagrama combinado de Implantação e componentes

IGUAL

Diagrama de Casos de Uso Diagrama de Casos de Uso IGUAL

Diagrama StateChart Diagrama de Máquina de Estados

Só alterou o nome, IGUAL.


UML – o que há de novo? [1]

UML 1.4 UML 2.0 MudançaDiagrama Estado do Protocolo NOVO. Máquina de estado em um

nível mais alto.

Grafo de Atividades Diagrama de Atividades Refinado e melhorado

Diagrama Estrutura de Composição

NOVO. Combinação entre o diagrama de objeto e diagrama de objeto composto.

Diagramas de Interação

Diagrama de Colaboração Redistribuido entre os novos diagramas de interação.

Diagrama de Seqüência Diagrama de Seqüência

Diagrama de Comunicação

Diagrama de Interação

Diagrama de Tempo


UML – Mecanismos de Extensibilidade

• Estereótipos, tagged values e restrições são conhecidos omo mecanismos de extensibilidade da UML [1].

• Permitem a personalização dos diagramas UML para um assunto específico [1].

• A UML também oferece os comentários como mecanismo para anexar significado em texto livre.

• As restrições são conhecidas como condições invariantes e podem ser expressas formalmente em qualquer diagrama através de OCL (Object Constraint Language)

• Vejamos alguns detalhes…



• Estereótipos [5]

Permitem adicionar novos elementos ao UML



• Tagged values (marcas com valor) [5]

Permitem adicionar novas propriedades aos elementos.



• Restrições (constraints) [5]

Consiste na especificação de uma condição delimitada pelos caracteres ‘{‘ e ‘}’.

A condição pode ser especificada em linguagem formal (OCL) ou informal (ex. Salário maior que zero).



• Outro mecanismo de extensão:

Perfis [1]

• Um perfil é um meio de personalizar o uso da UML para um domínio ou plataforma específica.

• Os perfis utilizam uma combinação entre mecanismos de extensão para ajustar a notação da UML.

• Exemplos de perfis UML (Profiles UML) já padronizados pela OMG:

Perfil para processos de desenvolvimento de software; Perfil para modelagem de negócio.



• Profile UML for Data Modeling Padrão ainda não aprovado pela OMG; Situação atual:

Ver RFP: RFP_IMM_DataModeling__05-12-02.pdf


• Estado da Arte

UML Profile para Banco de Dados

• Desenvolvido pela Rational Software Corporation;

• O conceito de tabelas e relacionamentos usados em bases de dados são mapeados para os conceitos de classes e associações em UML.

UML Data Modeling Profile


Nodes (nó):

• Representação de uma entidade física (computador) onde o banco de dados está localizado. • A representação de nó faz parte do Core da UML.• Usa o Deployment Diagram, pois ele representa a configuração física de um Software Deployment.



Tablespaces:

• Representam o armazenamento dos dados.

• A representação do BD usa uma dependência ligada a um ou mais Tablespaces.

• Representado por um estereótipo <<Tablespace>>



Database:

• Representa o próprio sistema de gerenciamento do Banco de Dados.



Schema:

• Representa a unidade básica de organização das tabelas.• É representado por um pacote que recebe o estereótipo <<schema>>.




Tables (tabelas):

• Representação da estrutura básica de modelagem. • Representa um conjunto de registros de uma mesma estrutura (linhas).• Uma tabela é uma classe estereótipada com um pictograma. • Usa o Deployment Diagram, pois ele representa a configuração física de um Software Deployment.



Columns (colunas):

• Elemento básico organizacional dentro de um BD relacional.

• São modelados como atributos estereótipados.

• Adiciona um tagged value para o data type.


Views: • Modelada como uma classe, com o estereótipo <<View>>.

• O estereótipo <<Derived>> : quando uma view modelada com dependência de duas ou mais tabelas.



Keys (chaves): • Primary Key: única e identifica uma coluna na tabela. Representada pelo estereótipo <<PK>>;• Foreign Key: derivada do relacionamento com outras tabelas. Representada pelo estereótipo <<FK>>;• Em caso de uma Foreign Key ser usada como Primary Key, a combinação das chaves são representadas pelo estereótipo <<PFK>>.



Index (índice): • Estrutura física de rápido acesso aos dados. Representada pelo estereótipo <<Index>>;



Constraints (regras):

• Representam regras aplicadas à estrutura do banco de dados;• Vários tipos de constraints podem ser definidas:

• Primary key - <<PK>>• Foreign key - <<FK>>• Trigger - <<Trigger>>• Value verification - <<Check>>• Uniqueness - <<Unique>>



Relacionamentos:

• Classificados em:• Non-Identifying : representa o relacionamento entre duas tabelas diferentes.



Relacionamentos:

• Classificados em:• Identifying : representa o relacionamento entre duas tabelas dependentes.



Stored Procedures: Identificadas pelo estereótipo <<SP Container>>;



Técnica proposta por [10]: • Baseado na proposta da Rational [9];

• Procura oferecer uma proposta de mapeamento entre o diagrama de classes da UML e um diagrama de banco de dados relacional;

• Define uma regra de mapeamento de um dmodelo de classes para um modelo relacional através de 11 passos.

Mapeamento Classes -> RDB


Passo 1 [10]:

• Modelo de classes:

• Primeiramente deve-se assumir que queremos gerar um modelo relacional de dados a partir de um modelo de classes que possuímos.



Passo 2 [10]:

• Identificar Objetos Persistentes:

• Possuindo o diagrama de classes, devemos identificar os elemento do modelo que necessitam ser persistidos e os que não precisam.

• Por exemplo, numa arquitetura MVC, apenas as classes da camada Model necessitam de estado persistente.



Passo 3 [10]:

• Assumir cada objeto persistente como uma tabela:

• Deixar de tratar momentaneamente as questões de herança.

• Cada classe torna-se uma tabela.

• Cada linha da tabela assumirá o registro de um objeto da classe.



Passo 4 [10]:

• Definir a estratégia de herança escolhendo um método básico:

• Forma 1 – A classe pai agrupará todos os atributos das classes especializadas e formará uma tabela apenas.

Bom para seleções!!

• Forma 2 – As classes especializadas agruparão além dos seus atributos, também os atributos da classe pai.

Evita valores nulos!!

• Forma 3 – As classes especializadas e a classe pai continuarão com a mesma estrutura e não será necessário agrupar atributos em um ponto específico.

Reflete o modelo como ele é!!



Passo 5 [10]:

• Para cada classe adicionar um identificador único de classe:

• Em ambos os mundos OO e Relacional existe a necessidade de definir identificadores únicos;

• O método mais conveniente é definir um OID (Object Identifier);



Passo 6 [10]:

• Mapear atributos para colunas:

• Mapear cada atributo da classe para uma coluna da tabela;

• Atributos complexos serão vistos nos próximos passos;



Passo 7 [10]:

• Mapear associações para foreign keys:

• Atributos de classe mais complexos são representados como associações;

• Uma associação é uma representação estrutural entre objetos;

• Para cada associação no modelo de classes considerar a criação de uma foreign key na tabela filha, da tabela pai.



Passo 8 [10]:

• Mapear agregações e composições:

• São similares a representação da associação, com a adoção de um par PK-FK;


Passo 9 [10]:

• Definir regras de relacionamentos:

• É basicamente nomear o relacionamento e adicionalmente acrescentar novas constraint, como {NOT NULL};


Passo 10 [10]:

• Comportamento do Modelo:

• Este passo consiste na representação de capacidades funcionais do modelo, como triggers, stored procedures, uniqueness e data contraints (validate check, etc.);


Passo 11 [10]:

• Produzir o modelo físico:

• Descrever através de diagrama como é feito o deployment do modelo criado no mundo real, especificando host, schema, tablespaces, etc.


Roteiro

• Motivação

• Objetivo


• Estado da Arte


• Referências


[1] - Pender,T., UML a Bíblia. Rio de Janeiro: Elsevier, 2004.

[2] - IBM- Rational Software. UML Data Modeling Profile.

[3] – Ferreira, Alex., Análise de Ferramentas de Modelagem UML Gratuitas.

[4] – Correia, José., UML – Unified Modeling Language, Março 2006.

[5] – Silva, A. Videira, C., UML, Metodologias e ferramentas CASE.

[6] – OMG Unified Modeling Language Specification, version 1.4, september

2001.[7] - OMG Unified Modeling Language (OMG UML), Infrastructure, V2.1.2,

November 2007.[8] - OMG Unified Modeling Language (OMG UML), Superstructure, V2.1.2,

November 2007.[9] – Gornik, Davor, UML Data Modeling Profile, Rational Software, IBM.[10] – Sparks, Geofrey, Databse Modeling in UML, Methods & Tools e-

Newsletter, Spark Systens.

Referências

in1008 – projeto conceitual de bd

Documents