Pontíficia Universidade Católica de Minas Gerais

MINI- CURSO: Mapeamento UML para

XML

Professora: Msc. Claudete Moscardini

Maio de 2003

1
 Índice

Introdução a Linguagem de Modelagem Unificada (UML)................................................3

XMI (XML Metadata Interchange).....................................................................................5
3. Mapeamento UML para XML.........................................................................................7
3.1 Mapeamento do diagrama de classe para DTD XML...........................................8
3.1.1 DTD relaxada......................................................................................................8
3.1.2 DTD restrita........................................................................................................9
3.2 Mapeamento do diagrama de objetos para documento XML..............................10
3.2.1 Classe................................................................................................................10
3.2.2 Herança.............................................................................................................10
3.2.3 Atributos UML para XML................................................................................11
3.2.4 Atributos enumerados.......................................................................................11
3.2.5 Associações UML para XML...........................................................................12
3.7 Relevância da linguagem XML ..........................................................................13
Referência Bibliográfica....................................................................................................14

2
Introdução a Linguagem de Modelagem Unificada (UML)

Devido a rápida percepção dos benefícios da OO (Orientação a Objetos), verificou-se o

surgimento de um grande número de propostas de análise e projeto orientados a objeto,
tanto dos meios acadêmicos quanto empresariais. As primeiras propostas de notações
para a Análise OO surgiram no início da década de 90 e logo após houve uma miscelânia
de notações, gerando um excesso de propostas para a diagramação e construção de
sistemas com técnicas OO. O que dificultou a adoção das técnicas OO foi a falta de um
acordo na escolha do método a seguir. Entre as propostas de Análise OO mais robustas,
destacam-se os seguintes autores:

• Peter Coad / Edward Yourdon com Análise Baseada em Objetos

• Jacobson com OOSE (Object-Oriented Software Engineering)
• Rumbaugh com o método OMT (Object Modeling Technique)
• Grady Booch

Diante de várias técnicas fez com a OMG1 (Object Management Group) aprovasse a
UML em 1997. A UML segundo o autor Eduardo [BEZERRA, 2002] é uma mistura de
sintaxe gráfica preexistentes, com alguns elementos removidos e outros elementos
adicionados com o objetivo de torná-la mais expressiva. A UML é destinada para
visualizar, especificar, construir e documentar sistemas complexos.

Segundo [BOOCH,2000], a UML é adequada para a modelagem de sistemas, cuja

abrangência poderá incluir desde sistemas de informação corporativos a serem
distribuídos em aplicações baseadas em Web, até sistemas complexos embutidos em
tempo real.

Conforme [BOOCH,2000], diagrama é a representação gráfica de um conjunto de

elementos, geralmente representados como gráficos de itens e relacionamentos. É através
dos diagramas que se pode visualizar o sistema. É difícil um único tipo de diagrama
representar o ciclo de vida de um projeto, por isso, a UML disponibilizou vários tipos de
diagramas para mostrar a estrutura e comportamento de um sistema sob várias
perspectivas. A UML é composta de nove diagramas.

Os diagramas são utilizados nas seguintes fases do projeto:

1. Análise
⇒ Use Cases
⇒ Classes
⇒ Objetos
2. Projeto
⇒ Seqüência
⇒ Colaboração
⇒ Estados
1
Consórcio internacional de empresas que define e ratifica padrões na área da orientação a objetos.
(www.omg.org).

3
 ⇒ Atividades
3. Implementação
⇒ Componentes
⇒ Deployment

O comportamento de um sistema tem aspectos dinâmicos e estáticos que são observados

ao longo do projeto e distribuidos em diagramas específicos. São diagramas estáticos, o
Diagrama de use case, o Diagrama de classe, o Diagrama de objetos, Diagrama de
componentes e Diagrama de implantação. São diagramas dinâmicos; o Diagrama de
interação, Diagrama de seqüência, Diagrama de colaboração, Diagrama de atividade e
gráfico de estado.

Diagrama de classe é o diagrama mais encontrado nos sistemas orientados a objeto. É

composto de classes, interfaces, colaboração e relacionamentos (dependência,
generalização e associação). O Diagrama de objetos representa a instância de um
diagrama de classe.

O Diagrama de use case, conforme [BOOCH,2000], é importante principalmente para a

organização e a modelagem de comportamento do sistema. Fornece um modo de
descrever a visão externa do sistema e suas interações com o mundo exterior,
representando uma visão de alto nível da funcionalidade comportamental mediante o
recebimento de requisições dos atores externos (usuário, outro sistema, um hardware,
etc.). A modelagem do use case é utilizada não somente para capturar os requisitos de um
novo sistema, mas também para desenvolver novas versões de um sistema.

Segundo [JONES,2001], o diagrama de estado, ou gráfico de estado como é chamado por

[BOOCH,2000], refere-se ao diagrama de transição de estado da análise estruturada para
o desenho orientado a objeto.

Segundo [JONES,2001], existem sete pontos importantes da UML que foram definidos
pelos próprios autores:

1. Prover aos usuários uma linguagem de modelagem visual expressiva e pronta para
uso, de forma que eles possam desenvolver e compartilhar modelos significativos.
2. Prover mecanismos de extensibilidade e especialização para ampliar os conceitos
centrais.
3. Ser independente de linguagens de programação e processos de desenvolvimento
particulares.
4. Prover uma base formal para entendimento da linguagem de modelagem.
5. Estimular o crescimento do mercado de ferramentas orientadas a objetos.
6. Suportar conceitos de desenvolvimento de nível mais alto, tais como
colaborações, estruturas, modelos e componentes.
7. Integrar as melhores práticas.

A UML, segundo [FURLAN,1998], pode ser usada ao longo do ciclo de vida de

desenvolvimento de um sistema para:

4
 1. Mostrar as fronteiras de um sistema e suas funções principais utilizando atores e
casos de uso.
2. Ilustrar a realização de casos de uso com diagramas de interação.
3. Representar uma estrutura estática de um sistema utilizando diagramas de classe.
4. Modelar o comportamento de objetos com diagramas de transição de estado.
5. Revelar a arquitetura de implementação física com diagramas de componente e de
implantação.
6. Estender sua funcionalidade através de estereótipos.

XMI (XML Metadata Interchange)

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

Hoje os fabricantes de ferramentas de projeto e de banco de dados têm adicionado o XMI

aos seus produtos possibilitando assim a troca de informações com outras ferramentas.
XMI é um sistema aberto a qualquer um que queira usufruirem da sua capacidade de
troca de informações e com isso evitar formatos proprietários de cada fornecedor.

A especificação XMI define uma rigorosa abordagem para geração de uma DTD XML à
partir de um metamodelo, e para geração de um documento XML como modelo
instânciado do metamodelo.

XMI é uma tecnologia da OMG, mas é baseado no padrão XML da W3C, por isso ele é
conhecido por integrar três padrões: XML da W3C, UML e MOF, os quais são padrões
de modelagem da OMG. Essa integração permite que desenvolvedores de sistemas
distribuídos compartilhem modelos de objeto e outros metadados via Internet.

A figura 2.1 abaixo mostra as camadas da arquitetura MOF, onde pode-se observar que
outros padrões de modelos são metamodelos instanciados do modelo MOF.

5
 Modelo MOF

Camada M3

Metamodelo Metamodelo Metamodelo

UML CWM Esquema XML

Camada M2

Modelo de CatML Esquema BD Relacional XML Schema ou

DTD

Camada M1

Camada M0
Dados Documento XML
Objetos

Figura 2.1 - Camadas da arquitetura MOF[CARLSON,2001]

O padrão XMI foi projetado para permitir a troca de qualquer modelo de metadados
especificado segundo o metamodelo MOF, e é composto de dois componentes principais:
regras de produção de Document Type Definitions (DTDs) XML, que expressam
como produzir DTDs para metadados codificados em XMI; e regras de produção de
documentos XML, que expressam como codificar metadados em documentos XML
válidos e bem formados.

XMI define uma rigorosa abordagem para geração de uma XML DTD a partir de um
metamodelo e a geração de um documento XML de modelo instanciado do metamodelo.
Exemplificando essa abordagem na figura 2.2 abaixo, é possível ver alguns atributos
padrões da sintaxe XMI e suas definições [CARLSON,2001].
Atributo XMI TIPO Definição
xmi.id ID Define um identificador do elemento que
contém esse atributo.
xmi.idref IDREF O valor desse atributo deve ter um
valor xmi.id correspondente em um
outro elemento dentro do mesmo
documento.
xmi.label CDATA Fornece uma descrição para esse
elemento.
href CDATA Contém um ponteiro para um elemento
dentro do mesmo documento ou que esteja
em outro documento..
xmi.value CDATA Esse atributo XML contém um dos valores
da lista de enumeração, definida na
DTD.
Figura 2.2 – Padrão de atributos xmi

6
 3. Mapeamento UML para XML

Esta seção foi baseada no livro do Carlson [CARLSON,2001] onde é claramente

exemplificado o mapeamento de um diagrama de classe para DTD XML e um diagrama
de objeto para um documento XML.

[CARLSON,2001] explora dois mapeamentos:

1. Objeto instanciado para documento XML: uma instância de um diagrama de
classe que é conhecido por diagrama de objetos e pode ser exportado em um ou
mais documentos XML.
2. Diagrama de classe para o esquema XML: classes, atributos e associações são
exportadas para uma DTD XML ou Schema XML os quais são utilizados para
validar um documento XML.

A figura 3.1 abaixo ilustra o relacionamento entre UML e XML. O esquema XML gerado
através do diagrama de classe é utilizado para validar o documento XML que poderá ser
gerado da instância do diagrama de classe. Observe que a instância do diagrama de classe
tem um relacionamento bi-direcional com o documento XML, o que significa que uma
instância de um diagrama de classe pode gerar, ou ser gerada, de um documento XML.

UML

Instância
Mapeamento
utilizando XMI
Diagrama Esquema
de Classe XML

Instância Validado
Mapeamento
Diagrama de utilizando XMI Documento
Objeto XML

Figura 3.1 - Mapemento UML para XML [CARLSON,2001]

7
 3.1 Mapeamento do diagrama de classe para DTD XML

Um projeto OO não gera automaticamente uma DTD XML, por isso o mapeamento deve
utilizar regras de consistência para mapear um projeto OO para uma DTD XML. Essas
regras de mapeamento são especificadas pela XMI, e podem gerar uma DTD restrita ou
relaxada. A DTD relaxada permite um mapeamento com menos limitações que a DTD
restrita como exemplo, pode-se considerar o caso do mapeamento de um atributo UML
para elemento ou atributo XML. Na DTD restrita, o atributo UML é mapeado apenas
para elemento XML e na DTD relaxada é possível mapear tanto para elemento XML
quanto para atributo XML.

3.1.1 DTD relaxada

Regras XMI de geração de uma DTD relaxada:

1. Permite que o modelo seja fragmentado em vários modelos.
2. Não é obrigatória a ordem dos subelementos dentro de um elemento.
3. Não é obrigatória a escolha de um elemento ou de um atributo ao fazer o
mapeamento UML para a estrutura XML.

Uma classe UML é mapeada para um elemento XML e todos os atributos e

relacionamentos pertencentes a essa classe também produzem elementos XML. As regras
da XMI 1.1 especificam que atributo XML ou elemento XML são originados dos
atributos, classes ou regras de associação do diagrama UML. Uma classe do tipo
<<enumeration>> também produz tanto um atributo quanto um elemento XML que
define a lista de valores.

A tabela apresentada na figura 3.9 abaixo representa os critérios para gerar uma DTD
relaxada a partir de um modelo UML:

Critério Descrição
Mapeamento de Namespace Conforme [AMARAL,2002], DTD não suporta a
declaração de vários namespaces, um modelo UML
pode ser representado com um ou nenhum namespace.
Unicidade do nome do Utilizar o nome da classe como prefixo no nome do
elemento atributo.
Elementos ou atributos Um elemento XML representa um atributo UML e
regras de associação.
Um atributo XML representa um atributo UML e tem
tipo primitivo com multiplicidade maxima igual a um.
Multiplicidade Todos os elementos XML têm multiplicidade ilimitada.
Todos os atributos XML que representam regras de
associações como IDREFs, podem ser ilimitados.
Herança Não é suportada pela DTD; copia todos os atributos da
classe pai para a classe filho.
Ordem dos elementos Não existe uma ordem pré-definida dos elementos.
Tipo de dados A DTD permite apenas tipos de dados: CDATA para

8
 atributos e PCDATA para elementos.
Lista de valores Conforme [AMARAL,2002], para classe UML com
estereótipo <<enumeration>>, devem ser produzidos
um elemento e um atributo que descrevam a lista
enumerada de valores.
Linking Usar atributo do tipo HREF para fazer links a outras
fontes de dados. Usar ID e IDREF para fazer links
dentro do próprio documento.
Figura 3.2 - Critérios de uma DTD relaxada[CARLON,2001]

3.1.2 DTD restrita

Comparando a DTD relaxada diante das características gerais da DTD com mapeamento
restrito, pode-se sumarizar os seguintes itens:
❏ Restrições de multiplicidade de acordo com o modelo UML.
❏ Apenas elementos XML são gerados, os atributos não são gerados.
❏ Ordem de seqüência do conteúdo do modelo para forçar a multiplicidade.

Devido à limitações da linguagem da DTD, a multiplicidade pode ser forçada apenas se

for definida a ordem de seqüência do conteúdo do modelo, que são os nomes dos
elementos separados por “,”.

Na tabela abaixo são representados os critérios para gerar uma DTD restrita:

Critério Descrição
Mapeamento de Namespace Conforme [AMARAL,2002], DTD não suporta a
declaração de vários namespaces, um modelo UML
pode ser representado com um ou nenhum namespace.
(Semelhante a DTD relaxada).
Unicidade do nome do Utilizar o nome da classe como prefixo no nome do
elemento atributo. (Semelhante a DTD relaxada).
Elementos ou atributos Gerar um elemento XML para cada atributo e cada
associação.
Regras de multiplicidade É forçada com modelo de conteúdo, usando: branco,
“?”, “*” ou “+”. Atributos UML com multiplicidade
não definida assumem ser únicos, sem repetições.
Herança Não é suportada pela DTD; copia todos os atributos da
classe pai para a classe filho. (Semelhante a DTD
relaxada).
Ordem dos elementos Os elementos aparecem na mesma ordem especificada
no modelo de classe da UML.
Tipo de dados A DTD permite apenas tipos de dados: CDATA para
atributos e PCDATA para elementos. (Semelhante a
DTD relaxada).
Linking Usar atributo do tipo HREF para fazer links a outras
fontes de dados. Usar ID e IDREF para fazer links

9
 dentro do próprio documento.(Semelhante a DTD
relaxada).
Figura 3.3 - Critérios da DTD restrita

3.2 Mapeamento do diagrama de objetos para documento XML

Descrever-se-ão o mapeamento de classe, herança entre classes, atributos, atributos que

contêm checks (onde só é permitida uma lista pré-definida de dados), agregação e
associações.

3.2.1 Classe

Cada mapeamento de classe gera um elemento XML. O tag gerado tem o mesmo nome
da classe UML desde que essa tenha um nome válido, pois o nome do tag não pode
conter espaços, permite caracteres especiais como “-” e “.”. O nome do tag deve ser
iniciado com uma letra ou “_”. A XMI permite mas não obriga o uso de namespace como
parte do nome de um tag.

3.2.2 Herança

De acordo com [FURLAN,1998], herança é a capacidade de um novo objeto tomar

atributos e operações de um objeto existente, permitindo criar classes complexas sem
repetir códigos.

O padrão XML não apresenta uma maneira de representar herança. Uma DTD não
representa herança entre elementos definidos. Como resultado dessa limitação, XMI
especifica o uso da copia dos atributos da super classe para subclasse.

10
O exemplo abaixo, citado por [AMARAL,2002], mostra que a subclasse “PessoaFisica”
copia os atributos da super classe “Cliente”.
<PessoaFisica>
<Cliente.codigo> 1567 </Cliente.codigo>
<Cliente.nome>José da Silva</Cliente.nome>
<Cliente.endereco>Rua das Flores 500</Cliente.endereco>
<Cliente.telefone>3245-9876</Cliente.telefone>
<Cliente.telefone>9932-6768</Cliente.telefone>
<PessoaFisica.CPF> 12345678977</PessoaFisica.CPF>
<PessoaFisica.Renda>1700</PessoaFisica.Renda>
.....
</PessoaFisica>

Figura 3.4 - Exemplo de mapeamento de herança

3.2.3 Atributos UML para XML

Um atributo UML pode ser mapeado para um elemento XML ou para um atributo XML.
Na primeira abordagem o mapeamento é praticamente direto onde o nome do atributo
UML é qualificado com o nome da classe (exemplo: cliente.telefone, cliente é a classe e
o telefone é o atributo).

Na segunda abordagem existem algumas restrições de atributos multi-valorados como é o

caso de “telefone” onde um cliente pode informar mais de um. Então só é possível
mapear para elemento, uma vez que não é permitido haver repetições de nomes de
atributo XML dentro de um mesmo escopo. O conteúdo do atributo deve estar entre
aspas. Pode-se verificar no exemplo abaixo [AMARAL,2002]:

<PessoaFisica codigo = “1567” nome = “José da Silva” CPF =

“12345678977”>
<Cliente.endereco>Rua das Flores 500</Cliente.endereco>
<Cliente.telefone>3245-9876</Cliente.telefone>
<Cliente.telefone>9932-6768</Cliente.telefone>
<PessoaFisica.Renda>1700</PessoaFisica.Renda>
Figura 3.12 - Exemplo de mapeamento de atributo UML para XML
.....
</PessoaFisica>

3.2.4 Atributos enumerados

Um tipo de atributo enumerado requer que o valor do atributo UML esteja presente em
uma lista pré-definida. Exemplificando, um atributo “DiaSemana” só poderá conter os
dias da semana (“segunda”, “terça”, “quarta”, “quinta”, “sexta”, “sábado” e “domingo”).
Esse atributo pode ser especificado em um documento DTD, conforme estrutura a seguir:
<!ATTLIST Agenda.DiaSemana xmi.value( Segunda | Terça | Quarta | Quinta | Sexta |
Sábado |Domingo) #REQUIRED>

11
A especificação do padrão XMI contém dois mapeamentos de valores enumerados de
UML para documento XML. Através da DTD é possível checar se o conteúdo do atributo
é válido ou não. No primeiro seria um mapeamento normal para atributo XML apenas
diferenciado pela validação que a DTD faz do conteúdo. A figura 3.13 abaixo representa
esse mapeamento.

<Agenda DiaSemana = “quarta” >

<Agenda.HoraInicial> 08:00 </Agenda.HoraInicial>
<Agenda.HoraFinal> 08:50</Agenda.HoraFinal>
<Agenda.Aula> APSII </Agenda.Aula>
...
</Agenda>

Figura 3.5 - Exemplo atributo enumerado

A segunda opção de mapeamento utiliza um elemento que possui o atributo xmi.value,

que refere-se a uma característica do XMI. No exemplo abaixo da figura 3.14, o elemento
“DiaSemana” contém um atributo com o conteúdo igual a “quarta”, sendo esse conteúdo
validado pela DTD, através das listas de enumeração pré-definida:
<Agenda >
<Agenda.HoraInicial> 08:00 </Agenda.HoraInicial>
<Agenda.HoraFinal> 08:50</Agenda.HoraFinal>
<Agenda.Aula> APSII </Agenda.Aula>
<Agenda.DiaSemana xmi.value = “quarta”/>
...
</Agenda>

Figura 3.6 - Exemplo atributo enumerado utilizando xmi.value

3.2.5 Associações UML para XML

Conforme [FURLAN,1998], uma associação é apresentada quando duas classes,

apresentam interdependência, onde determinada instância de uma delas origina ou se
associa a uma ou mais instâncias da outra.Uma associação também pode envolver uma
mesma classe, neste caso é conhecida por recursiva.

O relacionamento entre dois objetos é auxiliado por algumas características introduzidas

pelo XMI, como o atributo xmi.id que é o identificador para o elemento que contém esse
atributo. O xmi.id pode ser referenciado por outro elemento dentro do mesmo documento
XML. Essa referência é para um atributo xmi.idref, esse atributo pode conter ou não um
outro atributo conhecido por xmi.label, o qual contém uma descrição ou o título do
elemento referenciado, sendo esse último mais utilizado para documentação.Veja
também a figura 3.5 acima.

Uma outra alternativa seria associar o atributo xmi.id a um elemento para receber o
conteúdo de referência. Pode-se visualizar essa abordagem na figura 3.15 abaixo onde
tem-se um funcionário contendo dois dependentes.

12
 ......
<Funcionario xmi.id = “r1”>
<Funcionario.nome> João da Silva </Funcionario.nome>
</Funcionario>

<Dependente.nome> “Luiz Henrique da Silva”</Dependente.nome>

<Dependente.idade> 22 anos</Dependente.idade>
<Funcionario xmi.idref = “r1” xmi.label = “Dependente do funcionário r1”
/>

<Dependente nome = “Pedro Paulo da Silva” dependente = “r1”>

<Dependente.idade> 18 anos</Dependente.idade>
</Dependente>

Figura 3.7- Exemplo de associações entre objetos

3.7 Relevância da linguagem XML

Os quatro fatores abaixo são pontos importantes para ter-se optado por XML neste
trabalho:
 A XML viabiliza a troca de dados entre computadores em redes heterogêneas.
 XML é a linguagem padrão da Web para intercâmbio de dados.
 Hoje existe um número grande de aplicações sobre XML.
 Baixo custo, da recuperação das informações. Uma vez que informações de um
SGBD podem ser acessadas por outros computadores que não possuam esse tipo
de software.
 A troca de informações via XML se torna mais rápida devido a ausência de
formatação do arquivo.
 E mais objetivo uma vez que as informações são contextuais, ou seja, estão dentro
das marcações que dão mais semântica aos dados do documento.

13
Referência Bibliográfica

[AMARAL, 2002] AMARAL, Juliana Alves. Intercâmbio de Frameworks

especificados em UML-F através das estruturas XML para apoiar o
desenvolvimento de softwares. Belo Horizonte: PPGEE da PUC Minas, 2002.
Dissertação de mestrado.

[BEZERRA, 2002] BEZERRA, Eduardo. Princípios de Análise e Projeto de Sistemas

com UML. Ed. Campus. Rio de Janeiro, 2002.

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

[CARLSON, 2000] CARLSON, David. Modeling XML Applications With UML.

Addison-Wesley. 2000.

[FURLAN, 1998] FURLAN, José Davi. Modelagem de Objetos através da UML- São
Paulo: Makron Books, 1998.

14