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

Gerenciando Componentes de Software com XML e Banco de Dados Relacional

Este artigo apresenta o projeto de um catálogo de componentes de software descrito em XML (EXtensible Markup Language), que pode ser acessado via Web e armazenado utilizando tecnologia relacional.  

Introdução 

As empresas precisam ser competitivas, criar produtos com qualidade, baixo custo e rapidez,  para sobreviver no mercado. Através do uso de componentes de software, a troca de informações e o reuso de códigos já prontos têm ajudado nesse objetivo.

No acompanhamento da vida de um componente, seu histórico e composição são de importância relevante para os projetistas, evitando retrabalho e má utilização dos mesmos. É necessário, assim, estabelecer modelos que representem as características básicas de um componente e também possibilitem a troca de informações entre as equipes de projeto.

Um componente é uma unidade de software com um conjunto de serviços (operações), desenvolvida pela própria empresa, comprada de fornecedores ou disponível sob o formato open source. Um componente possibilita que vários serviços sejam acoplados e disponibilizados parareuso. Sua utilização faz com que um software fique mais barato, aumenta a produtividade - muitas necessidades de desenvolvimento já podem ter sido solucionadas em projetos anteriores - e por fim, diminui ou elimina os erros, pelo fato de o componente já ter sido testado em outros programas.

Neste projeto de catálogo de componentes são necessárias algumas etapas que possibilitem manter as informações em um banco de dados e a sua troca via Web, através da linguagem XML. Este artigo está dividido em três partes: na primeira, todas as informações necessárias sobre componentes serão modeladas utilizando o diagrama de classes UML (Unified Modeling Language); na segunda, esse diagrama sofrerá algumas alterações para que, através da ferramenta IBM XMI Toolkit, seja possível gerar uma estrutura de documento XML. Por último, um banco de dados  relacional será projetado para manter a estrutura e o conteúdo deste documento.

Nota: O XMI ToolKit foi incorporado ao projeto Eclipse, uma iniciativa da IBM que mantém um conjunto de ferramentas gratuitas para desenvolvimento, e agora é denominado EMF (Eclipse Modeling Framework). Maiores informações e o download free estão disponíveis em http://www.alphaworks.ibm.com/tech/xmitoolkit. Por motivos didáticos, este artigo utiliza o nome antigo da ferramenta.

XML

XML é uma linguagem de marcadores flexíveis (tags), que permite ao usuário criar seus próprios marcadores de acordo com a sua necessidade. Um documento XML contém tags do tipo elemento, subelemento e atributo. No exemplo da listagem 1 a idade é um atributo do elemento pessoa. O nome e email são subelementos de pessoa. O valor do atributo sempre é uma string e deve estar entre aspas.

O conteúdo de um documento XML está contido entre tags de início e fim. Observe que o conteúdo Alan está entre a tag de início <NOME>e a tag de fim </NOME>.

<PESSOA idade="“42”">

Listagem 1 - Documento XML com elementos e atributo

Existem hoje duas linguagens de esquema para representação de um documento XML. O DTD (Document Type Definition) que é o original, incluído na especificação XML, e o XML Schema também recomendado pela W3C (World Wide Web Consortium), que veio superar algumas limitações do primeiro.

O DTD contém a estrutura de um documento XML, onde é possível extrair as informações dos elementos (e subelementos) podendo detalhar cada um deles através da obrigatoriedade (REQUIRED ou IMPLIED), cardinalidade, lista de dados possíveis, entre outros.

Quando o documento XML segue a estrutura definida em um DTD ou XML Schema, pode-se dizer que o documento é válido.  Observe na listagem 2 um DTD para o conteúdo descrito na listagem 1.

.......

Listagem 2 - Exemplo de um DTD

A troca de informações através de XML pode ser particularmente útil entre equipes de desenvolvedores de software que utilizem ferramentas diferentes. Baseando-se em XML, o XMI (XML Metadata Interchange) surgiu para resolver o problema da interoperabilidade de ferramentas através do fornecimento de um formato flexível de intercâmbio.

XMI

XMI é um formato padrão recomendado pela OMG (Object Management Group) desde 1999, que tem como objetivo o intercâmbio de modelos entre ferramentas de projeto diferentes. XMI possibilita a transferência de modelos UML e metamodelos MOF (Meta-Object Facility), através do padrão XML DTD.

Hoje, os fabricantes de ferramentas de modelagem e de banco de dados têm adicionado o XMI aos seus produtos, possibilitando a troca de informações irrestritas com outros programas. É um sistema aberto que evita o aprisionamento em formatos de propriedade de algum fornecedor.    

A especificação XMI define uma rigorosa abordagem para geração de um DTD XML a partir de um metamodelo, e para geração de um documento XML instanciado deste metamodelo. O XMI, apesar de ser uma tecnologia da OMG, é baseado no padrão XML da W3C. Assim, ele é conhecido por integrar três padrões: XML, UML e MOF. Essa integração permite que desenvolvedores de sistemas distribuídos compartilhem modelos de objeto e outros metadados via internet. Na figura 1 observamos outros padrões de modelo instanciados do MOF.

Figura 1 - Camadas da arquitetura MOF

O padrão XMI foi projetado para permitir a troca de qualquer modelo de metadados especificado segundo o metamodelo MOF, e é composto por duas classes de regras: as que expressam como produzir DTDs para metadados codificados em XMI; e as que expressam como codificar metadados em documentos XML válidos e bem formados.

IBM XMI Toolkit

A ferramenta XMI Toolkit, desenvolvida pelo alphaWorks (grupo de trabalho da IBM sobre tecnologias emergentes), possibilita a troca de objetos Java usando XML, além de gerar DTDs a partir de modelos UML projetados com Rational Rose (arquivos .mdl), através do padrão XMI.

Visão geral

A figura 2 apresenta o modelo funcional do sistema proposto. Neste projeto, os componentes são modelados por dois diagramas de classes UML. O primeiro apresenta um modelo conceitual que abstrai as informações sobre componentes. O segundo define um modelo lógico que prepara o modelo anterior para sua representação através de documentos XML. 

Figura 2 – Modelo funcional do sistema proposto

O modelo lógico é mapeado, utilizando a sintaxe XMI, para um DTD XML. Esse DTD será importado para um banco de dados, possibilitando então que o conteúdo de um documento XML seja validado antes de ser importado ou exportado. Consultas a dados poderão ser feitas e o resultado será retornado ao usuário via documento XML.

Na figura 3 temos uma visão em camadas do modelo funcional da figura 2. Na camada de projeto é realizada a análise e projeto do catálogo de componentes. A segunda camada, denominada de XMI, é responsável pelo mapeamento do diagrama de classes e do diagrama de objetos para os documentos DTD e XML, respectivamente. O DTD é criado com o apoio da ferramenta XMI Toolkit. O mapeamento do diagrama de objetos para XML ainda é feito manualmente.

A terceira camada refere-se a ferramenta chamada de IE-XML, que ainda está em desenvolvimento e permitirá importar um documento DTD e importar/exportar um documento XML para o banco relacional.

Figura 3 – Visão arquitetural em camadas da proposta

Modelos Conceitual e Lógico

         O modelo conceitual utiliza a notação UML e define o problema a ser resolvido abstraindo-se dos detalhes de implementação. Neste caso, o problema são os componentes utilizados no desenvolvimento de um software. Uma vez que o objetivo do projeto é a utilização de XML como padrão para troca de informações, fez-se necessário o mapeamento do modelo conceitual para um modelo lógico, deixando-o preparado para gerar o DTD. Este modelo foi concebido tendo em vista o uso da ferramenta XMI Toolkit para a geração automática de DTDs a partir de diagramas de classe UML.

Modelo Conceitual

         A bibliografia pesquisada sobre análise e projeto de sistemas orientados a objetos descreve os componentes de software da seguinte maneira:

1. Têm uma interface externa separada da implementação interna, promovendo então o conceito de encapsulamento. O usuário não toma conhecimento de como as operações são desenvolvidas;

2. Possuem operações, cada uma delas com argumentos de entrada e saída e com pré e pós-condições;

3. Não são gerados em diversas cópias, cada reprodução tem suas próprias características;

4. Dependem do meio no qual são implantados;

5. Provêem certo conjunto de operações demandadas pelo meio nos quais eles são implantados;

6. Podem interagir com outros componentes (reutilização);

7. São comercializados ou distribuídos sob a forma de executável (código binário), em vez da forma compilável (código-fonte). Potencialmente, é permitida a interação entre componentes escritos em diferentes linguagens;

8. Podem publicar (durante o período de desenvolvimento ou no tempo de execução) as operações que suportam, para que outros componentes as descubram e as utilizem.

Com base nas definições acima, foi projetado o modelo conceitual da figura 4. Um catálogo de componentes é essencialmente uma agregação[1] de componentes, cada um deles associado a uma ou mais palavras-chave. Um componente tem uma ou várias versões, representadas na classe ComponenteVersionado. Essas versões têm um a vários autores (programadores responsáveis) e também um a vários métodos (operações) disponíveis. Parte dos métodos pode ser disponibilizada para as aplicações através da interface.

 Uma aplicação pode ser dividida em módulos que contenham os métodos necessários com os respectivos parâmetros de entrada ou saída. Os sistemas estão em constante evolução e a vida útil de um componente versionado em um módulo é representada pelos atributos DataInclusao e DataExclusao. A DataExclusao pode estar vazia, indicando que o término do ciclo de vida da versão ainda não ocorreu.

O ciclo de vida da versão de um componente é representado pelo atributo situação, que pode assumir os seguintes estados: estável, obsoleto ou em desenvolvimento. Um componente em desenvolvimento é aquele que ainda não disponibilizou uma versão para ser utilizada. Um componente estável corresponde à versão confiável e atualmente em uso. Cada componente só pode ter uma versão estável. A versão obsoleta é aquela versão funcional, que não é aconselhada para utilização, mas que é preservada para registro histórico.

Figura 4 - Diagrama de classe do modelo conceitual

Modelo Lógico

O modelo conceitual da figura 4 precisou ser mapeado para um modelo lógico que expressasse uma solução viável de implementação em algum modelo físico (XML ou relacional). Então, o modelo lógico foi criado para atender as características de uma definição de estrutura de dados DTD XML.

As regras de mapeamento da UML para XML podem gerar um DTD restrito ou relaxado. O DTD relaxado, como o próprio nome diz, permite um mapeamento mais flexível. Por exemplo, um atributo UML pode ser mapeado tanto para atributo XML como para elemento XML. Já no DTD restrito, só ocorre mapeamento do atributo UML para elemento XML. A ferramenta XMI Toolkit implementa o mapeamento restrito, cujas características são sumarizadas abaixo:

·As restrições de multiplicidade são mapeadas de acordo com aquelas definidas pelo modelo UML;

·Apenas elementos XML são gerados; os atributos não são gerados;

·A ordem de seqüência do conteúdo do modelo UML é preservada para forçar a multiplicidade de atributos e associações.

Baseadas nas características do DTD restrito, propomos abaixo algumas regras de mapeamento do modelo conceitual para modelo lógico UML:

1. Como a referência em XML é implementada por um ID, optou-se por adicionar um atributo UML de domínio ID nas classes do modelo lógico, para identificar o elemento XML;

2. Para referenciar o ID de um elemento, tem-se em XML o identificador de referência IDRef. Optamos então por utilizar um atributo IDRef nas classes, com o objetivo de representar relações de associação, herança e agregação do modelo conceitual;

3. Para os atributos que definem previamente uma lista de valores possíveis de entrada, foi criada uma classe chamada de <> contendo esses valores. Na classe que contém o atributo, o domínio será o nome da classe <> correspondente;

4. Caso uma classe se relacione com mais de uma classe é necessário ter-se tantos IDRef quantos forem o número de classes relacionadas. Como não é permitido que diferentes atributos de uma mesma classe compartilhem o mesmo nome, faz-se necessário acrescentar no final do IDRef um número seqüencial. (IDRef1, IDRef2,...IDRefN);

5. No relacionamento N:N, apenas uma classe recebe o IDRef que referencia a outra classe;

6. Os atributos UML terão apenas os domínios ID, PCData (tipo abstrato) ou nome da classe referenciada. Isso se deve ao fato da ferramenta XMI Toolkit só gerar DTD restrita;

A figura 5 apresenta o diagrama UML resultante da aplicação das regras acima a uma parte do diagrama da figura 4.

Figura 5 - Modelo lógico: catálogo de componentes

Mapeamento XML para Modelo Relacional

O modelo relacional é adotado pela maioria dos sistemas de gerenciamento de bancos de dados, tanto os comerciais quanto os gratuitos. Além disso, ele oferece mecanismos para manipulação de dados padronizados com SQL e é suportado por um grande número de ferramentas. Por estas razões, foi projetado um modelo relacional para guardar as definições dos dados (DTD) e o conteúdo de um documento XML.

As tabelas DTD, DTDelemento, subelemento, elemento e seqüência da figura 6 são responsáveis por manter as informações do DTD XML.

O conteúdo de um documento XML é mantido na tabela conteúdo. Este conteúdo está associado a um subelemento, uma vez que os subelementos são as tags delimitadoras do conteúdo.

Figura 6 – Modelo físico relacional

Para ilustrar o conteúdo destas tabelas, consideremos o DTD restrito gerado pela ferramenta XMI Toolkit a partir da classe ComponenteVersionado do modelo lógico da figura 5, apresentado na listagem 3. 

-- _______________________________________________________________ -->                                           

            XMI.value ( Sim | Nao ) #REQUIRED>

            XMI.value ( Estavel | Desenvolvimento | Obsoleto ) #REQUIRED>

                                ComponenteVersionado.Raiz?,

                                ComponenteVersionado.DataGeracaoVersao?,

                                ComponenteVersionado.Situacao?,

                                ComponenteVersionado.ID?,

  ComponenteVersionado.IDRef?,

  ComponenteVersionado.IDRef1?

                                ComponenteVersionado.Descricao)?

  XMI.extension*,

  ComponenteVersionado.autor*,

  ComponenteVersionado.metodo*)?>

            %XMI.element.att;

            %XMI.link.att;>

Listagem 3 - Representação parcial do arquivo DTDcatalogo.DTD gerado pela ferramenta XMIToolkit

A tabela DTD guarda o nome do DTD e o elemento raiz. A figura 7 mostra um exemplo de instância desta tabela.

Figura 7 - Tabela DTD

A tabela elemento contém os elementos XML. Na tabela subelemento estão contidos todos os atributos UML, ou subelementos do DTD. Para o elemento ComponenteVersionado definido pelo DTD da listagem 3 tem-se o armazenamento mostrado nas figuras 8 e 9.

Figura 8 – Tabela Elemento

Figura 9 - Tabela Subelemento

As colunas Obrigatorio, PK e FK são restritas apenas à entrada de dados ‘S’ (Sim) ou ‘N’ (Não). A coluna Tipo também tem uma restrição de entrada, permitindo apenas ‘E’ (elemento XML) ou ‘A’ (atributo XML). Sabe-se que a ferramenta XMI Toolkit não gera DTD com atributos XML; mesmo assim, o banco está preparado para possíveis alterações tanto na ferramenta como manualmente na DTD. Ao gerar o documento XML é importante saber qual é a classe UML referenciada pelo IDRef; por isso, foi inserida uma coluna chamada OrigemIDRef.

Na figura 10 tem-se a tabela DTDelemento, originada de um relacionamento N:N entre as tabelas DTD e subelemento. Esta multiplicidade permite a um subelemento estar contido em vários DTDs distintos.

Figura 10 - Tabela DTDelemento

A tabela seqüência (figura 11) guarda as restrições de conteúdos possíveis para os elementos. Como exemplo, o subelemento situacao permite apenas as entradas dos valores estável, em desenvolvimento ou obsoleto.

Figura 11 - Tabela seqüência

            O documento XML contém um conjunto de tags e conteúdos, que referem-se à estrutura do DTD projetado. Assim, é obrigatória a escolha de um DTD previamente cadastrado no banco, possibilitando a validação do documento XML a ser importado. Essa estrutura possibilita gerar, a qualquer momento, um documento XML a partir de uma consulta a um DTD existente na base de dados.

As tabelas apresentadas até o momento armazenam a estrutura de um DTD. O conteúdo XML propriamente dito é mantido pela tabela Conteúdo.

A coluna Registro possibilita o agrupamento lógico das informações de um objeto. Ao importar o conjunto de dados de uma instância da classe, essa coluna recebe o mesmo conteúdo. Na figura 12 existem duas instâncias da classe ComponenteVersionado: a primeira contém as linhas referentes ao registro L1 e a segunda contém as linhas referentes ao registro L2.

Figura 12 - Tabela conteúdo

Browser XML

A ferramenta IE-XML gerencia o conteúdo de arquivos DTD e XML armazenados no banco.Desta maneira, ela é responsável por importar o conteúdo de um documento XML e a estrutura DTD para a base de dados. Também é permitido a um usuário solicitar à IE-XML uma consulta aos dados, informando em qual estrutura DTD ele quer que seja apresentado o resultado. A ferramenta IE-XML recupera e monta um documento XML, a partir da DTD escolhida.

Esta ferramenta está sendo construída em PHP, acessando um banco de dados MySQL. Atualmente, um protótipo implementando a importação de DTDs e a importação/exportação de documentos XML está em fase de testes, e em breve estará disponível aos leitores desta publicação.

Conclusões

Neste artigo foi apresentada uma proposta de gerenciamento de componentes utilizados em desenvolvimento de software, mantendo os dados em um banco de dados relacional e permitindo a troca de informações entre as equipes via Web. O gerenciamento de componentes permite um aumento de produtividade e diminuição de redundância de código, gerando um sentimento nas equipes de estarem produzindo software com alto grau de aproveitamento.

Ponto importante deste projeto: a opção de um repositório XML tornou-o flexível. Se guardássemos o modelo de componentes diretamente no banco de dados, estaríamos engessando o sistema a uma regra de negócios específica. Da maneira como foi proposto, é permitido que qualquer DTD ou documento XML seja mantido no banco, independente da regra do negócio. Por exemplo, se o usuário necessitasse controlar componentes, clientes ou fornecedores, normalmente seriam necessários três modelos conceituais para cada sistema e três esquemas para o banco. Através do mapeamento para XML, a camada de banco de dados proposta neste artigo comporta qualquer modelo conceitual. Diferentes relatórios em XML podem ser gerados com consultas SQL sobre a estrutura relacional proposta.

Referências Bibliográficas

[ABITEBOUL, 2000] ABITEBOUL, Serge; BUNEMAN, Peter; SUCIU, Dan. Data on the Web: From Relations to Semistructured Data and XML. Morgan Kaufmann Publishers, 2000.

[BOOCH, 2000] BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML-Guia do Usuário, Rio de Janeiro, Editora Campus, 2000.  

[CARLSON, 2001] CARLSON, David. Modeling XML Applications With UML. Editora Addison Wesley,2001.

[COMAI, 2001] COMAI, Sara; DAMIANI, Ernesto; FRATERNALI, Piero. Computing Graphical Queries over XML Data. ACM Transactions on Information Systems. October 2001,  Vol. 19, nr.  4, pp. 371-430.

[PAGE-JONES, 2000] PAGE-JONES, Meilir. Fundamentals of Object-Oriented Design in UML. Ed. Addison Wesley Longman, 2000. Cáp. 15.

[KROTH, 1999] KROTH, Eduardo; HEUSER, Carlos Alberto. Uma arquitetura de software para uso de componentes. Disponível na internet http://www.inf.ufrgs.br. Acessado em Abril/2002.

[MOSCARDINI, 2002] MOSCARDINI,Claudete. Uma ferramenta para gerenciamento e utilização de componentes em desenvolvimento de software baseada em XML. Dissertação de Mestrado. Outubro/2002.

[MYSQL] site: http://www.mysql.com. Acessado em 11/08/2002.

[PHP] site: http://www.php.net. Acessado em 19/07/2002.

[FLORESCU, 1999] FLORESCU, Daniela; KOSSMANN, Donald; Storing and Querying XML Data using na RDMBS. Bulletin of the Technical Committee on Data Enginnering, IEEE Computer Society, September 1999, vol. 22, nr. 3., pp. 27-34.

[RATIONAL, 2001] Rational. Using Rose, 2001.

[SILVA, 1999] SILVA, Ricardo Pereira e; PRICE, Roberto Tom. Suporte ao Desenvolvimento e Uso de Componentes Flexíveis.Anais do XIII Simpósio Brasileiro de Engenharia de Software. Florianópolis.13 a 15 de Oububro de1999. pág. 13 a 27.

[TURAU, 1999] TURAU, Volker. Making Data Accessible for XML Applications. Technical Report, available at http://www.informatik.fh-wiesbaden.de/~turau/DB2XML/index.html. Acessado em 07/05/2003.

[W3C, 2001] The World Wide Web Consortium. Extensible Markup Language(XML) 1.0 (Second Edition). Disponível em http://www.w3.org/TR/2000/REC-XML-2001006. Acessado em 08/05/2003.

[XMI Toolkit] Ferramenta da IBM(International Business Machines)  disponível na internet   http://www.alphaworks.ibm.com/XML. Acessada em 18/08/2002.

Excelente artigo sobre o eclipse em português: http://www.revistadolinux.com.br/ed/041/assinantes/eclipse.php3