1.

IN1008 – Projeto Conceitual de BD
UML for Design and Modeling Desenho e Modelagem de dados usando UML Por: Erick Araújo Gomes

Roteiro Motivação Objetivo Principais Conceitos Envolvidos
Estado da Arte Abordagem Prática Referências

Motivação 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;

Objetivos 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.

Roteiro Motivação Objetivo Conceitos Envolvidos Estado da Arte
Abordagem Prática 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]: Outro grupo desenvolveu outra especificação em paralelo e acabou se unindo ao primeiro para formar a UML 1.1 UML 1.0 como resultado da RFP proposta pela OMG, que gerou o consórcio UML Paterns (HP, IBM, ORACLE, etc.). Resultado da colaboração entre os três modelos União com Ivar Jacobson Objectory + Rational Software Corp. Resultado do trabalho de Booch e Rumbaugh em 1995.

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
Exemplo M3 Meta- metamodelo Define a linguagem para especificar metamodelos MOF 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 Meio de ajustar o uso para domínios de aplicações ou tecnologias específicas. Define um conjunto comum de tipos de dados válidos e enumerações para uso na definição do metamodelo da UML.

UML – Arquitetura UML 2.1.2 [7][8]: Pacotes do volume Infrastructure:
A especificação da UML está organizada em dois volumes: Infrastructure Superstructure (próximo slide) Metalinguagem CORE para reuso na definição de metamdelos, incluindo MOF, UML e CWM. Pacotes do CORE: Criação de novas línguas baseado no mesmo core de metalinguagem como UML. 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.

UML – o que há de novo? [1] UML 1.4 UML 2.0 Mudança
Diagrama de Classes IGUAL Diagrama de Objetos Tratado no Diagrama Estrutura de Composição UML 2.0 Diagrama Objeto Composto 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 Implantação Diagrama combinado de Implantação e componentes Diagrama de Casos de Uso 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ça
Diagrama 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 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__ pdf

UML Data Modeling Profile
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.

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>>;

Mapeamento Classes -> RDB
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.

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.

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 [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. 56 56

1.

Apresentações semelhantes

Apresentação em tema: "1."— Transcrição da apresentação:

Apresentações semelhantes

Sobre projeto

Feedback

Login

Autorizar-se através da rede social:

1.

Apresentações semelhantes

Apresentação em tema: "1."— Transcrição da apresentação:

Apresentações semelhantes

Sobre projeto

Feedback