Criando uma NIEM IEPD, Parte 1: Modele seu intercâmbio NIEM

Projete uma troca de informações XML entre agências governamentais dos EUA

O National Information Exchange Model (NIEM) está se tornando rapidamente o padrão de intercâmbio XML mais importante para o governo dos EUA e seus parceiros de informação. Esse artigo, o primeiro de uma série em quatro partes, fornece uma visão geral do processo para definir um intercâmbio de informações NIEM. Então, ele mostra a primeira etapa—modelar seu intercâmbio usando UML—com considerações especiais sobre os conceitos de modelagem NIEM. Um estudo de caso simples é usado para ilustrar o processo.

Priscilla Walmsley, Managing Director, Datypic

Photo of Priscilla WalmsleyPriscilla Walmsley é Diretora de Gerenciamento e Consultora Senior na Datypic. Ela é especialista em tecnologias, arquitetura e implementação XML. Mais recentemente, ela trabalha (por meio do Trusted Federal Systems) com o Departamento de Justiça dos EUA na LEXS, uma estrutura IEPD baseada em NIEM. Ela é autora de Definitive XML Schema (Prentice Hall, 2001) e XQuery (O'Reilly Media, 2007). Ela também é coautora de Web Service Contract Design and Versioning for SOA (Prentice Hall, 2008). É possível entrar em contato com a Priscilla pelo e-mail pwalmsley@datypic.com.



04/Jun/2010 (Primeira publicação 04/Jun/2010)

09 de março de 2010: Adicionados os links para a Parte 3 desta série nas seções de Introdução, Conclusão e Recursos.

09 de fevereiro de 2010: Adicionados os links para a Parte 2 desta série nas seções de Introdução, Conclusão e Recursos.

O National Information Exchange Model (NIEM) é uma iniciativa patrocinada pelo governo dos EUA para facilitar o compartilhamento de informações entre organizações dos setores público e privado. Seu foco inicial era o cumprimento da lei, a segurança pública e o gerenciamento de emergências, mas ela está sendo continuamente expandida para outros domínios. Novas iniciativas XML dentro do Departamento de Justiça e do Departamento de Segurança Nacional dos EUA, em conjunto com outros setores do governo dos EUA, usam o NIEM como um modelo de dados e uma metodologia de base comum para promover interoperabilidade de dados e software, reduzir o tempo de criação e desenvolvimento para aplicativos de intercâmbio de informações e permitir a reutilização de capital e habilidades intelectuais em projetos múltiplos.

O NIEM é descrito como uma estrutura, pois ele não é apenas um vocabulário XML para intercâmbio de informações. Ele possui vários componentes:

  • Um modelo comum de dados baseado em XML chamado NIEM principal que fornece componentes de dados para descrever objetos universais como pessoas, locais, atividades e organizações
  • Modelos de dados XML mais especializados para casos de uso individuais chamados domínios (os exemplos incluem Justiça, Imigração e Gerenciamento de Emergências)
  • Uma metodologia para usar e estender os blocos de construção vindos dos modelos comuns e específicos de domínio para torná-los um intercâmbio de informações completo, conhecido como um pacote de intercâmbio de informações
  • Ferramentas para ajudar a desenvolver, validar, documentar e compartilhar os pacotes de intercâmbio de informações
  • Uma organização de governança que fornece treinamento e suporte e examina a evolução do NIEM com o passar do tempo

Este artigo, o primeiro de uma série em quatro partes, introduz o NIEM e mostra como modelar um Information Exchange Package Documentation (IEPD) do NIEM usando Unified Modeling Language (UML). Os modelos UML de trabalho e final estão disponíveis na seção Downloads.

Como usar o NIEM?

O modelo de dados XML do NIEM fornece os blocos de construção para objetos comuns. Um bloco de construção pode estar em um nível muito granular, como um "nome de pessoa" ou "data de nascimento" ou pode ser um componente muito mais complexo, como "apreensão" ou "caso do tribunal". No entanto, o próprio modelo NIEM não define mensagens de intercâmbio de informações completas como "Relatório de Apreensão" ou "Relatório de Atividade Suspeita". Ele não designa qualquer tipo ou elemento-raiz específico de mensagens de documentos XML.

Para realmente usar o NIEM, é necessário construir uma IEPD. A IEPD retira os componentes necessários do NIEM principal e dos modelos de domínio e os estende para criar um intercâmbio de informações. Uma IEPD contém vários artefatos:

  • Esquemas XML que definem o subconjunto do modelo NIEM usado nesse intercâmbio, conhecido como o esquema do subconjunto
  • Um esquema que define o elemento-raiz do intercâmbio, conhecido como esquema do intercâmbio
  • Um esquema que define extensões para o modelo NIEM, conhecido como esquema de extensão
  • Documentação do intercâmbio, como diagramas UML, descrições narrativas e amostras

Desenvolvendo uma IEPD

A primeira tarefa em qualquer projeto de intercâmbio de informações é reunir e analisar seus requisitos. O NIEM não necessita de qualquer método particular de requisitos de definição, então, este artigo não descreve esse processo. Na verdade, este artigo considera que, antes de sentar para realmente criar sua IEPD, você possua uma ideia dos elementos de dados que gostaria de usar no intercâmbio e o tipo de mensagem no qual gostaria de estruturá-los.

Os artigos nesta série usarão um exemplo simples do início ao fim, obtendo, como resultado, uma IEPD completa. O estudo de caso de exemplo será implementar um relatório de roubo simples que cubra veículos registrados. Hipoteticamente, a polícia local usaria o relatório de roubo para informar às partes interessadas, como o Departamento de Trânsito ou o Escritório de Registro de Bicicletas da cidade, sobre os roubos de veículos motorizados ou bicicletas. Durante a fase de coleta de requisitos, colhi informações gerais sobre os dados que necessitam ser compartilhados e determinei que somente um tipo de mensagem é necessário: o relatório de roubo. Na verdade, uma IEPD consiste, frequentemente, em múltiplos tipos de mensagens relacionados.

Devido ao fato do principal objetivo do NIEM ser a interoperabilidade de dados, faz sentido considerar a reutilização de uma IEPD existente antes de criar uma nova a partir do zero. O NIEM fornece uma câmara de compensação IEPD que permite que você pesquise IEPDs existentes enviados por outras organizações. Consulte a seção de Recursos para obter um link para a câmara de compensação IEPD.

Caso não seja possível encontrar uma IEPD existente que seja adequado a suas necessidades, será necessário construir uma. O desenvolvimento de uma nova IEPD do NIEM necessita de cinco etapas:

  1. Modele seu intercâmbio.
  2. Mapeie seu intercâmbio para o modelo de dados NIEM.
  3. Crie um novo subconjunto do modelo NIEM para usar em seu intercâmbio.
  4. Crie esquemas de intercâmbio e extensão para descrever seus componentes customizados.
  5. Monte uma IEPD com todos os artefatos adequados.

Este artigo descreve a primeira etapa, o restante dos artigos nesta série cobrirão as etapas de 2 a 5. Mesmo que você escolha reutilizar uma IEPD existente, esta série de artigos ainda pode ser um guia útil para ajudá-lo a entender o conteúdo e a estrutura das IEPDs que você está usando.


Entendendo o modelo NIEM

Antes de criar um modelo para seu intercâmbio, seria útil entender como o modelo de dados NIEM é estruturado. O NIEM define conceitos—como tipos, propriedades e associações—com os quais você está, provavelmente, familiarizado devido a outros paradigmas de modelagem de dados.

Conceitos do modelo NIEM

Tipos representam coisas, tangíveis ou não. Alguns dos tipos mais fundamentais no modelo NIEM são PersonType, ActivityType, ItemTypeLocationType, e OrganizationType. Há também outros milhares, com diferentes graus de granularidade. Os tipos podem ser conhecidos como classes ou entidades em outros paradigmas de modelagem.

Propriedades são atributos de tipos. Elas podem possuir tipos complexos. Por exemplo, PersonName é uma propriedade de PersonType, mas também possui um tipo PersonNameType que possui sua própria estrutura contendo PersonGivenName, PersonSurName, etc.

Os tipos podem ser derivados de outros tipos e herdar suas propriedades, o que é análogo a generalizações em um modelo orientado ao objeto. Por exemplo, ItemType é um tipo genérico que possui muitos tipos derivados dele, incluindo VehicleType, JewelryType e RealEstateType.

Associações são relacionamentos entre dois tipos. É possível possuir uma associação entre um Incident e uma Person ou uma Person e um Location. Associações em um NIEM são separadas dos tipos aos quais se relacionam.

Roles representam afiliações temporárias que um tipo pode possuir em um contexto em particular. Por exemplo, em um incidente de roubo, uma pessoa pode desempenhar a função de Victim, Subject ou Witness.

Aumentos são pacotes configuráveis de propriedades que podem ser reutilizados e compartilhados. Esses são mais comumente usados nos modelos de domínio NIEM do que em suas IEPDs.

Metadados são informações sobre o conteúdo de uma mensagem, como quando as informações foram reunidas e o grau de confiabilidade. O NIEM faz provisões especiais em seu modelo para relacionar dados a metadados.

O modelo NIEM em XML

O modelo NIEM é totalmente implementado como um conjunto de documentos de esquema XML W3C. Anotações e referências dentro dos esquemas XML são usadas para indicar se algo é um tipo, uma associação, etc. Felizmente, não é necessário ler os próprios documentos de esquema XML para explorar o modelo; o NIEM fornece ferramentas para pesquisar e explorar o modelo de uma maneira mais gráfica.

Em geral, tipos NIEM são implementados como tipos complexos de esquema XML e propriedades são elementos contidos nesses tipos. A Listagem 1 mostra como uma atividade é representada por um tipo complexo ActivityType, com propriedades como ActivityIdentification e ActivityCategoryText implementadas como elementos filho.

Listagem 1. Implementação parcial do ActivityTipe do NIEM no esquema XML
<xsd:complexType name="ActivityType">
 <xsd:complexContent>
  <xsd:extension base="s:ComplexObjectType">
   <xsd:sequence>
    <xsd:element ref="nc:ActivityIdentification" minOccurs="0" maxOccurs="unbounded"/>
    <xsd:element ref="nc:ActivityCategoryText" minOccurs="0" maxOccurs="unbounded"/>
    <!-- ... -->
   </xsd:sequence>
  </xsd:extension>
 </xsd:complexContent>
</xsd:complexType>

O NIEM usa extensões de esquema XML para derivação de tipo. A Listagem 2 mostra como um tipo mais específico de atividade — o tipo complexo AssessmentType— é derivado de ActivityType.

Listagem 2. Derivação de tipo NIEM no esquema XML
<xsd:complexType name="AssessmentType">
 <xsd:complexContent>
  <xsd:extension base="nc:ActivityType">
   <xsd:sequence>
    <xsd:element ref="nc:AssessmentScoreText" minOccurs="0" maxOccurs="unbounded"/>
    <xsd:element ref="nc:AssessmentFee" minOccurs="0" maxOccurs="unbounded"/>
    <xsd:element ref="nc:AssessmentProgram" minOccurs="0" maxOccurs="unbounded"/>
    <!-- ... -->
   </xsd:sequence>
  </xsd:extension>
 </xsd:complexContent>
</xsd:complexType>

Associações são tipos especiais de tipos complexos que contêm referências aos tipos associados a eles. A Listagem 3 mostra como uma associação entre uma pessoa e uma atividade —ActivityPersonAssociationType— é implementada. Todos os tipos de associação são extensões (de maneira direta ou indireta) do NIEM principal AssociationType.

Listagem 3. Associação de tipo NIEM no esquema XML
<xsd:complexType name="ActivityPersonAssociationType">
 <xsd:complexContent>
  <xsd:extension base="nc:AssociationType">
   <xsd:sequence>
    <xsd:element ref="nc:ActivityReference" minOccurs="0" maxOccurs="unbounded"/>
    <xsd:element ref="nc:PersonReference" minOccurs="0" maxOccurs="unbounded"/>
   </xsd:sequence>
  </xsd:extension>
 </xsd:complexContent>
</xsd:complexType>

Modelando seu intercâmbio.

O NIEM não necessita que você use qualquer metodologia ou tipos de diagrama em particular para modelar seu intercâmbio XML ou até mesmo que você o modele. No entanto, a modelagem é uma etapa importante no design IEPD. O processo de modelagem inicia os requisitos e o resultado final fornece a documentação que é útil tanto para o negócio quanto para os usuários técnicos. O modelo também serve como uma entrada útil para as etapas subsequentes no processo de criação da IEPD.

Escolhendo um paradigma de modelagem

Usando ferramentas UML

Se você usar UML, há a vantagem de usar uma ferramenta UML habilitada para XMI, como o IBM® Rational® Modeler ou o ArgoUML, pois é possível usar o XMI para gerar, automaticamente, uma planilha de mapeamento, que pode ser usada na próxima etapa. Para este artigo, usei o ArgoUML, um editor de UML de software livre.

Uma boa opção é o UML — em particular, diagramas de classes UML —, pois conceitos UML são facilmente mapeados em conceitos de modelo NIEM. É claro que é possível criar outros diagramas UML, como diagramas de casos de uso e diagramas de sequência para documentar seu intercâmbio. Este artigo está focado no diagrama de classes, pois é o mais crucial para o processo de desenvolvimento da IEPD.

É melhor criar um primeiro rascunho de seu modelo de maneira independente, sem tentar ajustá-lo ao modelo NIEM. Você quer que o modelo seja correto para suas necessidades de negócios sem ser indevidamente influenciado pela maneira de fazer as coisas do NIEM. Posteriormente, no processo IEPD, é comum fazer pequenas alterações no modelo para que ele fique em melhor harmonia com o NIEM (em casos nos quais faz sentido). No entanto, sempre haverá diferenças entre seu modelo e o modelo NIEM.

Tipos e propriedades

Este artigo não é longo o suficiente para fornecer uma introdução completa à modelagem UML, então, ele foca nos ponteiros específicos do NIEM. Como pode ser esperado, os tipos NIEM são representados por classes em um diagrama de classes. Propriedades são representadas por atributos da classe.

Em meu estudo de caso de exemplo, determinei que possuo várias classes que necessitam de um intercâmbio — por exemplo Theft, MotorVehicle, Bicycle, Victim, Witness e TheftLocation. Esses tipos são ilustrados na Figura 1, junto às suas propriedades. (Consulte uma versão da Figura 1 somente em texto.)

Figura 1. Modelo UML inicial com tipos e suas propriedades
Initial UML model with types (Theft, MotorVehicle, Bicycle, Victim, Witness, TheftLocation) and their properties

Ao especificar os tipos de dados das propriedades, seria útil usar tipos de dados de primitiva do esquema XML, pois as propriedades serão, consequentemente, representadas em um esquema XML e será mais fácil determinar se o modelo NIEM existente se ajusta ao seu esquema se você usar um conjunto comum de tipos de dados. Os tipos de dados de esquema XML mais comumente usados estão listados na Tabela 1.

Tabela 1. Tipos de dados de esquema XML comuns
Nome do tipo de dadoDescriçãoExemplos
stringQualquer cadeia de caractere de textoabc, isso é uma cadeia de caractere
integerUm número inteiro de qualquer tamanho1, 2
decimalUm número decimal1.2, 5.0
dateUma data no formato AAAA-MM-DD2009-12-25
timeUm horário no formato HH:MM:SS (relógio de 24 horas)12:05:04
booleanUm valor verdadeiro/falsoverdadeiro, falso

Algumas propriedades possuem uma lista enumerada de valores válidos, também conhecida como lista de código. Os valores da lista de código podem ser descritos em um modelo UML em comentários ou documentados em algum outro local na documentação do sistema. No meu exemplo, para manter o modelo limpo, simplesmente listo essas propriedades como se possuíssem um tipo de dados code. Registrarei os valores válidos na planilha de mapeamento criada na próxima etapa do processo IEPD.

Generalizações e funções

O modelo NIEM usa generalizações e, quando for adequado, use-as também em seu modelo. No estudo de caso, MotorVehicle e Bicycle são, ambos, tipos de propriedades que podem ser roubados. Então, decidi adicionar uma classe Property mais genérica e derivar MotorVehicle e Bicycle dela. Fazer isso permite que eu defina as propriedades comuns, como SerialNumber somente uma vez e também simplificará associações permitindo que a classe Property seja associada à classe Theft.

Victim e Witness parecem seguir a mesma regra. Afinal de contas, ambas são tipos mais específicos de pessoas. No entanto, o estado de ser testemunha ou vítima de uma pessoa é temporário, então, ele é mais bem representado como uma função. Na verdade, neste caso, a mesma pessoa pode ser tanto uma vítima quanto uma testemunha em um roubo em particular. Neste caso, você desejaria representar uma pessoa com duas funções diferentes. Mostro isso em meu modelo adicionando uma classe Person separada e criando associações para as classes Victim e Witness. Rotulei as associações como Role Of Person, ou Função da Pessoa, para indicar que elas estão relacionadas através de uma função, ao invés de uma associação normal.

A Figura 2 mostra o modelo após ter adicionado minhas generalizações e funções. (Consulte uma versão da Figura 2 somente em texto.)

Figura 2. Modelo UML com generalizações e funções adicionadas
UML model with generalizations (Property, Person) and roles (Victim, Witness, MotorVehicle, Biycle) added

Relacionamentos

O UML possui três maneiras de representar relacionamentos: agregação, composição e associação.

Relacionamentos de agregação e composição representam, geralmente, relacionamentos do tipo "possui um(a)", nos quais uma classe está subordinada à outra. No estudo de caso de exemplo, uma Person "possui um" PersonName. A classe PersonName não é útil sem uma pessoa com a qual se relacionar. Agregações e composições são tratadas da mesma maneira no NIEM. Na estrutura XML resultante, a classe subordinada estará contida na outra classe. Por exemplo, haverá um elemento Person que contém um elemento PersonName.

Em contrapartida, associações ocorrem entre duas classes que podem ser independentes. No estudo de caso de exemplo, um Theft e um TheftLocation são duas coisas separadas, uma pode existir sem a outra. Para representar isso em seu modelo, é possível usar associações UML genéricas ou, caso haja propriedades adicionais que se relacionam a própria associação, adicione classes de associação separadas ao modelo. De qualquer maneira, na estrutura XML do NIEM, cada classe será representada como elementos distintos, com um elemento de associação separado que contém referências aos elementos aos quais está relacionando — neste caso, um Theft e um TheftLocation.

No caso de estudo de exemplo, uso a composição para representar o relacionamento Person-PersonName e associações UML simples para relacionar o restante das classes umas às outras. A Figura 3 mostra o modelo após ter adicionado meus relacionamentos. (Consulte a versão da Figura 3 somente em texto.)

Figura 3. Modelo UML com relacionamentos adicionados
UML model with relationships (aggregation, composition, association) added

Escolhendo uma raiz

Toda mensagem XML deve possuir uma raiz única. Geralmente, em um intercâmbio XML, há um ponto focal ou objetivo único para a mensagem. Em meu caso, é o próprio relatório de roubo. Adicionei uma classe para TheftReport ao meu modelo, em conjunto com uma propriedade TheftReportDate. Crio um relacionamento de agregação entre TheftReport e Theft, indicando que o relatório de roubo consiste em um conjunto de roubos.

O modelo UML completo é mostrado na Figura 4. Este modelo ainda não é perfeito, nem necessita ser. É comum fazer alterações iterativas no modelo durante o processo de desenvolvimento da IEPD. Por exemplo, pode ser útil modificar a estrutura ou os nomes para que se ajustem melhor ao modelo NIEM, onde for adequado. (Consulte uma versão da Figura 4 somente em texto.)

Figura 4. Modelo UML concluído
Completed UML model (with TheftReport class)

Conclusão e próximas etapas

Este artigo descreveu, em alto nível, as etapas envolvidas na criação de uma IEPD do NIEM e detalhou a primeira etapa: criação do modelo. O resultado é um rascunho de trabalho de um modelo UML que pode ser usado para continuar o desenvolvimento da IEPD. Usando conceitos direcionados ao NIEM, como funções e tipos de dados de esquema XML durante o processo de modelagem, facilita o restante do processo de desenvolvimento.

O próximo artigo desta série descreverá a segunda e a terceira etapa: mapeamento e subconjuntos. Você aprenderá como criar um modelo de mapeamento de componente que mapeia um modelo UML para o NIEM e gera um subconjunto do modelo NIEM para corresponder ao seu mapeamento.


Downloads

DescriçãoNomeTamanho
Final ArgoUML model from this articleniem1.zip12KB
Final XMI model from this articleniem1.xmi.zip4KB

Recursos

Aprender

Obter produtos e tecnologias

Discutir

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Segmentos de mercado
ArticleID=494450
ArticleTitle=Criando uma NIEM IEPD, Parte 1: Modele seu intercâmbio NIEM
publish-date=06042010