Example NIEM 3.0 Schema

This page provides an overview of defining a new NIEM compliant schema, from start to finish.

Import NIEM framework Packages

Modeling with NIEM in Enterprise Architect starts with the standard types defined by the NIEM Technical Architecture Committee and the Object Management Group NIEM-UML specification, as described here. These are available from our Reusable Asset Server and the Model Patterns wizard.

To import these into your model:

  • Open the Model Pattern Wizard to the 'Frameworks' page
  • Find the 'NIEM 3' group
  • Select the Packages required for your model


  • All NIEM 3 models require the NIEM 3 MPD Types Package as well as one of the NIEM 3 Reference Model Packages
  • All NIEM 2.1 models require the NIEM 2.1 Reference Model Package but not an MPD Types Package, as the NIEM 2.1 MPD elements are available from the NIEM 2.1 MPD Diagram Toolbox



NIEM 3.1 Framework

The power of NIEM comes primarily from the extensive library of types which you can use to build your own schemas. Enterprise Architect provides three versions of the complete NIEM framework, available from our Reusable Asset Server and the 'Model Patterns' dialog.

This tutorial is using the NIEM 3.1 framework, so select that pattern for import.

Model Package Description Types from NIEM-UML

A user defined NIEM schema is built around a Model Package Description (MPD) which defines, for consumers of the schema, how to use the various xsd files that are included and what message types are being defined.

When modeling in UML, an MPD is created using instances of a number of Classes defined in the UML Profile. Enterprise Architect provides these Classes in a Package that is available from our Reusable Asset Server and the 'Model Patterns' dialog.

All NIEM 3.x models will require these MPD types, so select the NIEM-UML MPD Types pattern for import.

Create Model Package Description

Previously, the framework Packages that are required for NIEM modeling were described. Both the Model Pattern Wizard and the Reusable Asset Server also provide a Package that acts as a convenient starting point for defining your MPD. When this is imported to your model you will find a diagram containing instances of the MPD types described above with the run-state set to show the core properties that you are most likely to need to set.

This section describes the process of taking the sample MPD from the pattern, and creating a 'Hello World' style message, where a request is made for a personalized message based on a facial image. The response will be the identity of the pictured person and a personalized message for them.



Model Package Description Metadata

The top level object in the pattern is an instance of the ModelPackageDescription Class. The name of the MPD is the name of the Object itself. All other properties are in the Run-State of the object.

This figure shows how it might look after providing real information.

NIEM-UML recommends the last section of mpdBaseURI matches the name of the MPD, and specifies that the mpdVersionID will be appended to the mpdBaseURI to produce the generated mpdURI. This example follows that convention.

The pattern defaults the value of mpdClassCode to iepd. This means that the MPD is intended to represent an Information Exchange Package Documentation (IEPD). This is the most common type of MPD, and it is what we want to create, so it has been left with the default value.

Defined Document Types

An IEPD is expected to define one or more document types. Each one will be an instance of IEPConformanceTargetType named 'IEPConformance Target'. The provided model pattern already includes one of these, but we need a second one as shown here:

Note the instances of QualifiedNamesType, with the qualifiedName relationship to a PropertyHolder. This specifies that the top level of the document being described will be an element from one of the contained attributes. The Create Extension Types section describes how this is defined. For now, an empty type will be enough.

Package Usage

The relationships connecting the Model Package Description to the Information Models, specify which schema files are to be generated with this MPD. In this example, we will use types from two different NIEM namespaces. To do this, we first create an InformationModel Package for each, where the Namespace Tagged Values match the original, and the purpose is set to subset. We will also need an extension Package where we can define our own types and how the NIEM types will be used.

This figure shows how this will look:

The relationships used also specify how the Package is used and the relative path to the schema defined by that Package.

Additional Files

All IEPD Packages are expected by NIEM to contain at a minimum a change log and a readme, but there are a number of other types of artifact that are also supported. In Enterprise Architect, each is defined using a stereotyped relationship to an Artifact. As with the Package use described above, the relationship specifies where the file will be located.

In this image a ReadMe, ChangeLog and a sample document for each of the document types are described. This will add information about those files to the target catalog file. The files will not be created by Enterprise Architect, and their content is beyond the scope of this tutorial.

Subset NIEM Namespaces

The Model Package Description is now complete, but we have three empty InformationModel Packages. The first two should be filled by selecting types and properties from namespaces within the NIEM framework Packages.

The model pattern includes a Schema Composer Artifact to use for specifying a subset. Double-click on it to open the Schema Composer and begin the subsetting process.

Our request message specifies that it will send a facial image to be used for facial recognition. To do that, we need to subset the appropriate types from the Biometrics Package.  Start by locating the type FaceImageType in the Domains\Biom package within the NIEM 3.1 Reference Model.  Drag this type into the Schema Composer.  The super types from which this type inherits, are automatically added to the Schema Composer.

Our response message requires PersonType from the NIEM Core Package.  Drag this type onto the Schema Composer as well.

This image shows the selection of a subset of the types and properties across a number of namespaces within the NIEM 3.1 Reference Model:

Once the required types are selected, you can generate the subset. When prompted, select the parent Package that contains the subset namespace packages to be generated. After generation, the Classes in the subset Package should resemble this:

We can now create a NIEM PIM diagram and place all our subset Classes on that diagram, to produce something that resembles this:

Create extension types

When describing the MPD earlier, we referred to a PropertyHolder that contained the possible document roots for our two messages. Now that we have defined our subset Packages we can define these document roots. Because we are only creating two simple document types, all that is needed is a PropertyHolder and ObjectType for each message. The ObjectTypes link to the types we've selected from the NIEM framework, to describe the contents of each message as shown:

Generate IEPD

Right click on the instance of the ModelPackageDescription.

Select 'Extensions | NIEM 3.0 | Generate NIEM 3.0 Schema'.

The dialog shows the standard NIEM artifacts and the list of linked namespaces that can be generated as schemas. Set the target directory and click on the Generate button to create the modeled MPD.

Learn More