1

IN1008 – Projeto Conceitual de BD UML for Design and Modeling Desenho e Modelagem de dados usando UML Por: Erick Araújo Gomes eag@cin.ufpe.br

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;

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

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

Contexto Evolutivo - UML Outras contribuições [4]:

Contexto Evolutivo - UML 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 2.1.2 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.

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

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…

UML – Mecanismos de Extensibilidade Estereótipos [5] Permitem adicionar novos elementos ao UML

UML – Mecanismos de Extensibilidade Tagged values (marcas com valor) [5] Permitem adicionar novas propriedades aos elementos.

UML – Mecanismos de Extensibilidade 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).

UML – Mecanismos de Extensibilidade 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.

UML – Mecanismos de Extensibilidade 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

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.

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.

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.

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

UML Data Modeling Profile Database: Representa o próprio sistema de gerenciamento do Banco de Dados.

UML Data Modeling Profile Schema: Representa a unidade básica de organização das tabelas. É representado por um pacote que recebe o estereótipo <<schema>>.

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

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

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

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

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

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

UML Data Modeling Profile Relacionamentos: Classificados em: Non-Identifying : representa o relacionamento entre duas tabelas diferentes.

UML Data Modeling Profile Relacionamentos: Classificados em: Identifying : representa o relacionamento entre duas tabelas dependentes.

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

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.

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

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

Mapeamento Classes -> RDB 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 é!!

Mapeamento Classes -> RDB 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);

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

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

Mapeamento Classes -> RDB 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};

Mapeamento Classes -> RDB 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 Principais Conceitos Envolvidos Estado da Arte Abordagem Prática Referências

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

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

57