Atenção: por essa edição ser muito antiga não há arquivo PDF para download.
Os artigos dessa edição estão disponíveis somente através do formato HTML.
Clique aqui para ler todos os artigos desta edição
Utilização de Padrões na Modelagem de Dados
Introdução
Um modelo de dados bem projetado é a melhor fundamentação que se pode dar para que os dados a serem processados sejam acessados de forma mais eficiente. Portanto, seu desenvolvimento é de fundamental importância para a qualidade final do sistema.
O desenvolvimento de um modelo de dados requer em última análise duas competências principais. Em primeiro lugar, o modelador deve estar intimamente ambientado com o domínio do negócio (ver Nota 1) a ser modelado. Isso porque o modelo de dados deve representar que informações relativas à organização estão envolvidas e que relacionamentos há entre essas informações.
Nota 1
Denomina-se domínio do negócio à área de conhecimento específica na qual um determinado sistema de software será desenvolvido. Ou seja, o domínio do negócio corresponde à parte do mundo real que é relevante ao desenvolvimento de uma aplicação.
A segunda competência que um modelador deve ter é dominar as técnicas de modelagem de dados. Ou seja, as notações, regras da linguagem de modelagem a ser utilizada e a sua forma da utilização.
Se você é um desenvolvedor experiente, já participou do desenvolvimento de diversas aplicações de software. Pare um pouco para se lembrar dos modelos de dados que você e o restante da equipe de desenvolvimento construíram. Talvez você perceba a semelhança entre os modelos de dados construídos para representar a disposição de empregados pelos órgãos (divisões, departamentos, etc) das organizações. Talvez você também note a semelhança existente entre a estrutura de um pedido de cliente e a estrutura de uma ordem de compra ao fornecedor, e que você teve que modelar esse mesmo conjunto de informações para diversas aplicações.
Do parágrafo anterior, subentende-se que os diversos problemas de modelagem aparecem de forma recorrente em muitas situações de modelagem de sistemas diferentes. Observando isso, alguns desenvolvedores começaram a documentar esses problemas e soluções genéricas para os mesmos. A partir daí, sempre que um problema já documentado aparecia em uma situação de modelagem, a solução utilizada era baseada na solução genérica correspondente. O resultado dessa documentação é denominado um padrão de software.
Este artigo descreve de forma resumida os padrões de modelagem de dados, que descrevem soluções para situações de modelagem de dados que comumente e repetidamente acontecem.
Modelando Dados Utilizando Padrões
Por definição, padrões de software são descrições genéricas e reutilizáveis de soluções para problemas que são recorrentes no desenvolvimento de software. Um padrão não resolve um problema específico a um domínio de negócio. Ao invés disso, um padrão de software fornece uma solução para uma família de problemas semelhantes. Não obstante, os padrões são abstrações que os desenvolvedores foram extraindo de múltiplas soluções específicas. Desse modo, padrões de software não são soluções para exemplos teóricos, e sim para problemas que ocorriam repetidamente no dia a dia dos desenvolvedores de aplicações.
Pode-se fazer uma analogia do conceito de padrão de software com o jogo de xadrez. Nesse jogo secular, diversos mestres já elaboraram jogadas geniais. No decorrer do tempo, diversas dessas jogadas foram registradas e passaram a ser utilizadas por outros jogadores. O mesmo acontece com os padrões. Desenvolvedores experientes e criativos criaram receitas de soluções para diversos problemas relacionados ao desenvolvimento de softwares. Assim como as jogadas de xadrez, o trabalho desses desenvolvedores experientes também foi documentado em padrões de software. Uma vez documentados, esses padrões podem ser utilizados por outros desenvolvedores.
Padrões de software podem ser utilizados para fornecer uma “velocidade inicial” ao desenvolvimento de software, através da disponibilização de uma solução bem conhecida e já testada. Dessa forma, a equipe de desenvolvimento pode focar sua atenção na solução de aspectos específicos para o sistema em questão, sem ter que perder algum tempo tendo que reinventar soluções para problemas já solucionados.
Historicamente e surpreendentemente, o conceito de padrões não foi concebido por profissionais da área de computação, mas sim por um arquiteto civil, Christopher Alexander. Erich Gamma e outros adaptaram o trabalho de Alexander para a computação e descreveram 23 padrões que podem ser aplicados ao desenvolvimento de sistemas de software orientados a objetos. Gamma e seus colaboradores criaram o catálogo clássico de padrões de projeto, que se encontra no livro Design Patterns: Elements of Reusable Object-Oriented Software (Padrões de Projeto: Soluções Reutilizáveis de Software Orientado a Objetos). Esse catálogo identifica e descreve 23 padrões que resolvem diversos problemas relacionados ao desenvolvimento de software orientado a objetos.
A maioria do esforço aplicado à produção de padrões tem sido na definição de padrões relacionados à fase de projeto do desenvolvimento de software. Entretanto, nos últimos anos diversos outros catálogos de padrões de software foram criados para documentar as soluções encontradas para problemas relativos aos mais variados aspectos e/ou fases do desenvolvimento de software. Desta forma, existem diversos outros catálogos de padrões propostos: padrões de análise, padrões de projeto (design), padrões de testes, padrões de arquitetura de sistemas, padrões de sistemas embutidos, padrões de projeto de interface gráfica com o usuário, etc.
Ultimamente, alguns profissionais têm se voltado para a identificação de padrões relacionados com a fase de análise. O termo padrão de análise foi cunhado por Martin Fowler em 1997 para designar esse tipo de padrão de software. Um padrão de análise captura modelos conceituais e domínios de aplicação de tal forma a possibilitar o reuso de artefatos de modelagem entre aplicações.
Padrões de modelagem de dados são padrões que se encaixam na categoria de padrões de análise e documentam problemas recorrentes em modelagem de dados e suas respectivas soluções genéricas.
Exemplos de Padrões para Modelagem de Dados
Existem diversos padrões para modelagem de dados descritos na literatura (ver Nota 2). Apresentarei agora sucintamente alguns desses padrões.
Nota 2
Existe um vasto material sobre padrões disponível na Web. Um bom material sobre padrões de software está acessível no site Patterns Home Page (http://st.www.cs.uiuc.edu/users/patterns/patterns.html). Um outro endereço Web que corresponde a uma autoridade no assunto é http://hillside.net/patterns/.
Além dos endereços Web citados acima, vale a pena o modelador de dados que se interesse por padrões adquirir pelo menos um dos seguintes livros sobre o assunto. O primeiro da lista é o livro clássico sobre o assunto padrões de projeto, não diretamente aplicáveis à modelagem de dados. Os livros seguintes são mais direcionados ao assunto padrões de modelagem de dados. O livro Data Model Patterns: Conventions of Thought, de David Hay, apresenta um conjunto de padrões de modelos de dados que descrevem soluções correspondentes à modelagem de situações típicas em aplicações de negócio. O livro de David Hay é também relevante para profissionais que trabalham na modelagem de sistemas orientados a objetos, pois ele apresenta padrões de modelagem comuns a muitos domínios de negócio. Finalmente, o livro de Martin Fowler apresenta diversos padrões aplicáveis à análise de domínio e apresenta diversos exemplos de implementação desses padrões em Java.
· Eric Gamma, Design Patterns: Elements of Reusable Object-Oriented Software (com tradução para o português pela editora Bookman. Padrões de Projeto: Soluções Reutilizáveis de Software Orientado a Objetos).
· David Hay, Data Model Patterns: Conventions of Thought, Dorset House, New York, NY, 1996.
· Robert J. Muller, Database Design for Smarties: Using UML for Data Modeling, Morgan Kaufmann, 1999.
· Martin Fowler, Analysis Patterns: Reusable Objects Models, Addison-Wesley, Reading MA, 1997.
Note que, normalmente, padrões de software em geral são documentados em um formalismo denominado linguagem de padrões, que significa essencialmente um catálogo de um grupo de padrões para resolver problemas correlatos. Por exemplo, no livro do Gamma, cada padrão é documentado pelas seguintes informações: nome, contexto, descrição do problema e descrição da solução. Na descrição feita neste artigo, não utilizo uma linguagem de padrões. Apresento apenas seu nome, solução e uma breve descrição.
A solução descrita por um padrão corresponde à estratégia utilizada para resolver o problema em questão. Nos padrões descritos a seguir, essa solução será apresentada em termos genéricos como um diagrama utilizando a UML. O modelador que utilize algum desses padrões deve traduzir o diagrama trocando os nomes de conceitos (classes ou entidades) e relacionamentos apresentados no padrão por nomes específicos do domínio de negócio em questão.
O Padrão Party
Esse padrão trabalha com o conceito de parte (party). Uma parte é uma generalização de uma pessoa ou de uma organização de interesse para a aplicação sendo modelada. A Figura 1 apresenta este padrão.
Na Figura 1, a classe Organização possui uma auto-associação que representa relações de subordinação entre pessoas e organizações, entre pessoas (e.g., que pessoas supervisionam outras), ou entre organizações (e.g., que organizações são subsidiárias de que outras).
Embora não seja exibido na figura, tanto Pessoa quanto Organização podem ter quaisquer atributos que sejam necessários em uma aplicação particular do padrão Party. Note também a existência da classe Emprego que representa associações entre empregados (pessoas) e empregadores (organizações). Essa mesma classe Emprego está associada à classe NomeaçãoCargo, e essa associação permite que se saiba que empregados assumiram que cargos em que organizações e em que períodos de tempo.
Finalmente, a classe associativa entre Parte e Local, LocalizaçãoParte, representa os endereços das pessoas e organizações e suas respectivas datas de estadia em cada endereço.
Figura 1. O Padrão Party
O Padrão Composite
Embora tenha sido elaborado no contexto de padrão de projeto, pode ser aplicado como padrão de modelagem de dados. O problema que esse padrão considera é o seguinte: como criar objetos utilizando partes de tal forma que tanto o objeto todo quanto os objetos parte forneçam a mesma interface para os seus clientes?
No contexto de bancos de dados, o padrão Composite pode ser utilizado para solucionar o problema de representar uma hierarquia de composição recursiva entre entidades. Esse problema é conhecido como “problema da explosão de partes” (parts explosion problem). O exemplo clássico desse problema é o da montagem de peças: uma peça é composta de diversas outras peças, e essas peças componentes são elas próprias compostas, e assim por diante.
A Figura 2 exibe o padrão Composite (somente as classes, sem atributos, nem operações). O Componente é uma classe abstrata (ou seja, não gera instâncias). Há dois tipos de componente, Folha e Composto. Uma folha não possui componentes, enquanto que um composto possui. A associação entre Composto e Componente é que representa a hierarquia de composição recursiva: um composto possui diversos componentes, que podem ser ou folhas ou outros compostos.
Figura 2. O Padrão Composite
O Padrão Metamodel
Considere um conjunto de itens. Cada item desse conjunto possui várias propriedades. Um caso particular dessa situação é o caso em que uma classe possui um grupo (fixo) de atributos, ou uma tabela é formada por uma quantidade (também fixa) de colunas. No entanto, as propriedades de cada item podem ser diferentes das propriedades dos outros itens do conjunto.
Por exemplo, considere os seguintes itens: Monitor, Modem, Teclado e Processador. Obviamente, as propriedades desses produtos não são as mesmas. É desejável criar no modelo de dados um único conceito para representar Produto, sem deixar de modelar as propriedades particulares de cada tipo de produto. Uma possível solução para esse problema é criar uma classe denominada Produto e criar diversas subclasses, uma para cada tipo de produto existente. Dessa forma, cada subclasse representaria as propriedades particulares do tipo de produto correspondente. Uma desvantagem dessa solução é que novos produtos estão sempre aparecendo e outros desaparecendo, o que levaria a uma modificação na estrutura de modelagem. Para complicar mais ainda, pode haver situações em que as propriedades de um mesmo item podem variar com o tempo (ou seja, novas propriedades podem ser adicionadas, ou propriedades existentes podem ser removidas). Se a solução descrita no parágrafo anterior fosse utilizada, haveria muitas mudanças no esquema do banco de dados, o que poderia acarretar em mudanças nas aplicações que utilizassem esse esquema.
O padrão Metamodel permite a “modificação" da estrutura de um banco de dados sem que o esquema desse banco de dados seja realmente modificado. O que acontece é que o esquema do banco de dados representa um metamodelo. Esse padrão é apresentado na Figura 3.
Figura 3. O Padrão Metamodel
Para entender como o padrão Metamodel funciona considere os equipamentos de computador citados no exemplo anterior. Considere ainda que dimensões, velocidade de transferência, quantidade de teclas e velocidade são atributos de Monitor, Modem, Teclado e Processador, respectivamente. Através do padrão Metamodel, esses atributos são representados como instâncias da classe Propriedade e cada item é representado como uma instância da classe Item. Finalmente, a classe valor é utilizada para representar o valor de uma propriedade de um determinado item.
Note que propriedades podem ser adicionadas (ou removidas) do metamodelo cuja base está no padrão Metamodel. Por exemplo, para adicionar o atributo formato ao item Monitor, basta adicionar uma nova linha à tabela correspondente ao mapeamento da classe Propriedade. Note também que é responsabilidade dos programas de aplicação apresentarem os dados como se eles fossem atributos da instância de Item. Pode haver inclusive um programa de aplicação que permita que os seus usuários adicionem (removam) atributos.
Conclusões
Vimos neste artigo que com a utilização de padrões de modelagem de dados, cada novo projeto não precisa começar do zero. Não importa se você utiliza o paradigma orientado a objetos ou estruturado, padrões de modelagem de dados (e padrões de software em geral) podem ser utilizados para a produção de modelos mais flexíveis e reutilizáveis.
Por outro lado, é importante também que você entenda que padrões de modelagem de dados são somente guias. Não se deve tentar forçar uma situação de modelagem em um padrão de modelagem. Se o padrão não se aplica, é mais adequado utilizar uma solução específica. Além disso, o padrão deve ser completamente entendido para que a sua correta aplicação possa ser realizada.
Por fim, um outro ponto importante é que um modelo de dados que utilize soluções de padrões de modelagem freqüentemente dá margem a diversas alternativas de mapeamento para um esquema relacional. Esse aspecto é contrastante com os modelos de dados resultantes de uma modelagem tradicional, cuja modelagem lógica freqüentemente se assemelha em estrutura a sua modelagem física. Portanto, deve-se tomar cuidado quando da passagem do modelo lógico para o modelo físico para que o desempenho do sistema não seja afetado.
