IN1008 – Projeto Conceitual de BD

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

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

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

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

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

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

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

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

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

11. 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. Contexto Evolutivo - UML • Evolução [1][3]:

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

13. UML – Arquitetura • Arquitetura de 4 níveis da OMG [1]:

14. UML – Arquitetura • Arquitetura de 4 níveis da OMG [6][7]:

15. UML – Arquitetura Três pacotes de alto nível • UML 1.4 [6]: 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.

16. UML – Arquitetura Pacotes do volume Infrastructure: • UML 2.1.2 [7][8]: • 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.

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

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

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

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

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

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

23. 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…

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

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

26. 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).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

43. UML Data Modeling Profile • Stored Procedures: • Identificadas pelo estereótipo <<SP Container>>;

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

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

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

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

48. 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 é!!

49. 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);

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