Atenção: esse artigo tem um vídeo complementar. Clique e assista!
Este artigo trata da modelagem de banco de dados usando uma extensão da UML para prover a modelagem relacional de banco de dados.
Para que serve
Serve como um guia apresentando uma extensão da UML para a modelagem de dados relacional e dicas para transformar modelos de objeto em modelos relacionais.
Em que situação o tema é útil
A UML tem se tornado um padrão mundial para modelagem de software. A sua aplicação também para a tarefa de modelagem de dados representa a unificação de uma linguagem para atuar no desenvolvimento de software, simplificando tarefas de desenvolvimento, projeto e manutenção.
Resumo DevMan
O modelo de classes na UML é o principal artefato produzido para representar a estrutura lógica de um software. Ele captura tanto os requisitos de dados como o comportamento dos objetos no domínio do modelo. A sua aplicação também para a tarefa de modelagem de dados representa a unificação de uma linguagem para atuar no desenvolvimento de software, simplificando tarefas de desenvolvimento, projeto e manutenção.
Quando é necessário prover um mecanismo de persistência de dados confiável, flexível e eficiente para sistemas computacionais, os projetistas de hoje se deparam com muitas escolhas. Na perspectiva tecnológica, a escolha usualmente é entre pura orientação a objetos, objeto-relacional híbrida, pura relacional e soluções customizadas baseadas em formatos abertos ou proprietários (exemplo: XML, OLE structured storage).
Este artigo aborda uma dessas escolhas, que seria a adoção de uma camada de modelo de classe orientado a objetos no topo de um banco de dados puramente relacional. Não estaremos discutindo se esta seria a melhor ou mais simples solução, mas pragmaticamente ela seria uma das mais comuns e uma das que possui mais potencial.
Começaremos com uma rápida volta por dois domínios de projeto que estaremos tentando integrar: primeiro o modelo de classes orientado a objetos como representado na UML (Unified Modeling Language) e segundo o modelo de banco de dados relacional.
Para cada domínio nós olharemos apenas as principais funcionalidades que irão afetar nossa tarefa. Iremos então olhar as técnicas e principais questões envolvidas no mapeamento do modelo de classes para o modelo de banco de dados, incluindo persistência de objetos, comportamento dos objetos, relacionamento entre objetos e identidade dos objetos. Iremos concluir com uma revisão sobre o Perfil de Dados da UML (UML Data Profile).
Iremos assumir que os leitores já possuem alguma familiaridade com projeto de software usando o paradigma de orientação a objetos, UML e modelagem relacional de dados.
O modelo de classes da UML
O modelo de classes na UML é o principal artefato produzido para representar a estrutura lógica de um software. Ele captura tanto os requisitos de dados como o comportamento dos objetos no domínio do modelo. As técnicas para descobrir e elaborar este modelo estão fora do escopo deste artigo, então iremos assumir a existência de um modelo de classes bem projetado que requer o mapeamento para um banco de dados relacional.
A classe é a entidade lógica básica no UML. Ela define tanto os dados como o comportamento de uma unidade estrutural. Uma classe é um template ou modelo a partir do qual instâncias ou objetos são criados em tempo de execução (durante o uso do software). Quando desenvolvemos um modelo lógico como uma hierarquia estrutural em UML nós explicitamente lidamos com classes.
Quando trabalhamos com diagramas dinâmicos da UML, como diagramas de sequência e colaboração, trabalhamos com objetos ou instâncias de classes e suas interações em tempo de execução.
O princípio do encapsulamento de dados é baseado na localização do efeito. Uma classe possui elementos de dados internos pelos quais ela é responsável. O acesso a esses elementos de dados deve ser através do comportamento exposto da classe ou alguma interface que esta disponibilize. A aderência a este princípio resulta em código mais simples de ser mantido.
• Comportamento de uma Classe
O comportamento é capturado no modelo de classes usando as operações que são definidas para as classes. Operações podem ser externamente visíveis (public), visíveis para as classes filhas (protected) ou escondidas (private). Através da combinação de dados escondidos com uma interface de acesso público e manipulação de dados escondidos ou protegidos, um projetista de classe pode criar unidades estruturais altamente simples de serem mantidas que suportam mudanças nos dados mais escondidos em um modelo de classes.
...
