NIEM UML Profile Initial Submission

AGENDA

• NIEM Overview• NIEM Technical Concepts• NIEM UML Profile Introduction• PIM Profile• PSM Profile• Next Steps and Way Forward

THE NIEM FORMULA FOR SUCCESS

Identification of large scale,

complex processes

Creationof the

standardized exchange

Governance and adoption

of the exchange

• Selection based on number of stakeholders and potential for reuse

• Complexity increases with numbers of entities involved• Benefit increases with numbers of implementations

WHAT IS NIEM – THE NIEM FRAMEWORK AND PROCESS

NIEM connects communities of people who share a common need to exchange information in order to advance their missions, and provides a foundation for seamless information

exchange between federal, state, local, and tribal agencies. Much more than a data model, NIEM offers an active user community as well as a technical and support framework.

THE NIEM FRAMEWORK

Support FrameworkTechnical FrameworkCommunity

Formal Governance Processes

Online Repositories

Mission-Oriented Domains

Self-Managing Domain Stewards

Data Model

XML Design Rules

Development Methodology

Predefined Deliverables (IEPD)

Tools for Development and Discovery

Established Training Program

Implementation Support

Help Desk & Knowledge Center

Translation

Scope-of-NIEM

NIEM intentionally does not address standardizing data inside legacy systems. NIEM serves as a translation layer (providing a common understanding) between and across disparate systems.

STANDARDIZING DATA MOVING ACROSS SYSTEMS

IN

TE

RF

AC

E

LEGACYDATABASES

LEGACYDATABASES

COMMONLY FORMATTED

DATA

IN

TE

RF

AC

E

THE NIEM DATA MODEL

Data elements are organized into core and domain-specific components

Core components are used by multiple domains and can be described by structure, semantics, and

definition universally

Domain-specific components are

continually updated by subject matter experts that are actual NIEM

participants and industry experts for their particular

domain

NIEM Naming and Design Rules (NDR) specify how each of

these components are defined and utilized

NIEM’s data model is a set of common, controlled, and approved XML data structures and definitions vetted through the Federal, State, Local, Tribal and Private Sectors.

Repeatable, Reusable Process(Exchange Specification Lifecycle)

Common Language(Data Model Lifecycle)

Built and governed by the business users at Federal, State, Local, Tribal and Private Sectors

THE NIEM LIFECYCLES

IEPD

– Developed to provide the business, functional, and technical details of the information exchange through predefined artifacts

– Created with a core set of artifacts in a prescribed format and organizational structure to allow for consistency

– Designed to be shared and reused in the development of new information exchanges through publication in IEPD repositories

IEPD COMPONENTS & REQUIREMENTS

<Exchange_Schema/>

<Extension_Schema/>

<Subset_Schema/>

IEPD IEM

Main Document

Catalog

Change Log

IEPD MPD

NIEM Core Schema(s)

Domain Schema(s)

Sample XML Instance

In order to be NIEM-conformant, the IEPD must adhere to:

1. NIEM Conformance Document

2. NIEM Naming and Design Rules (NDR) v1.3

3. NIEM Model Package Description (MPD) Specification v1.0

NIEM GOVERNANCE

NIEM GOVERNING STRUCTURE

NIEM’s governing structure is comprised of Federal, State, Local, Tribal and private organizations

NIEM is jointly managed at an executive level by the Department of Homeland Security (DHS), Department of Justice (DOJ), and Department of Health and Human Services (HHS)

Executive Steering Council

ESC

Executive DirectorDeputy Director

NIEM PMO

NIEM Technical Architecture Committee

NTACNIEM Business

Architecture Committee

NBACNIEM Communications &

Outreach Committee

NC&OC

WHO STEERS NIEM CURRENTLY?

Founders and Voting Members• Dept of Justice• Dept of Homeland Security• Dept of Health and Human Services

Ex-Officio Members• Global Justice Information

Sharing Initiative• Office of Management and Budget• Program Manager, Information

Sharing Environment• NASCIO

Partners• Terrorist Screening Center• Dept of Defense / Dept of Navy• Dept of State, Consular Affairs (invited)

UML PROFILE FOR NIEM

• Standardized model representing NIEM packages

• Build upon the scope of the existing profile to include support for MPD development

• Support “model-driven” IEPD development

• The profile will reflect NIEM architectural concepts and restrictions as set forth in the NIEM Naming and Design Rules (NDR) v1.3 and Model Package Description Specification (i.e. we don’t want to accommodate all of XML schema, only what is allowed by the NDR)

• End Goal: A developer (using supporting tools) should be able to generate an equivalent conformant MPD from any UML model that applies the envisioned UML profile properly. Conversely, a developer should be able to create an equivalent profiled UML model from a conformant MPD.

NIEM TECHNICAL CONCEPTS

NIEM CONFORMANCE

NIEM MODEL PACKAGES

NIEM MODEL PACKAGES

MPD Specification

MPD/IEM

IEPD Domain Update Release EIEM/BIEC

MPD: Model Package Description

IEM: Information Exchange Model

EIEM: Enterprise Information Exchange Model

BIEC: Business Information Exchange Component

IEM VS. MPDInformation Exchange Model (IEM)• One or more NIEM-conforming

XML schemas that specify the structure, semantics, and relationships of XML objects

• IEM Classes:– Release– Domain Update– Information Exchange Package

Documentation (IEPD)– Enterprise Information Exchange Model

(EIEM)

Model Package Description (MPD)• Compressed archive of files that

contains:– One and only one of the four NIEM IEM

classes– Supporting documentation– Other artifacts

<Exchange_Schema/>

<Extension_Schema/>

<Subset_Schema/>

IEPD IEM

<Exchange_Schema/>

<Extension_Schema/>

<Subset_Schema/>

IEPD IEM

Main Document

Catalog

Change Log

IEPD MPD

NIEM DOMAIN UPDATE SPECIFICATION

Provides normative rules and non-normative guidance for the packaging, content, and publication of domain updates; dependent on the MPD Specification

Domain updates that are conformant to the NIEM Domain Update Specification must also be conformant to the NIEM Model Package Description Specification

DOMAIN INDEPENDENCE AND SELF-SERVICE

Domain Independence

• Specifications and processes that decouple a domain from other domains and from Core

• Allows:• Domains to publish

updated content (domain updates) on their own timeline

• IEPD developers to use that new content immediately, without waiting for the next major or minor release

Domain Self-Service

• Development tools and collaboration areas that support domains in building and publishing their own content

• Allows:• Domains to use tools that

assist in content development and management

• NIEM to scale up more easily as the number of domains and the size of the model increase

DOMAIN UPDATE COMPONENTS & REQUIREMENTS

<Reference_Schema/>

Domain Update IEM

Catalog

Change Log

Domain Update MPD

Quality Assurance/Conformance Reports

In order to be NIEM-conformant, the Domain Update must adhere to:

1. NIEM Conformance Document2. NIEM Naming and Design Rules (NDR) v1.33. NIEM Domain Update Specification v1.04. NIEM Model Package Description (MPD) Specification v1.0

Namespaces provide a mechanism to uniquely identify an item in a distributed environment– Used to prevent “collisions” of types and elements because they

can only be used when referenced through a namespace– Needed when combining information from different sources– Elements with the same name could have different meanings– Abstract to more granular definitions

WHY NAMESPACES?

Namespaces allow for modification of parts of NIEM without impact on the rest of the model

Prevent “collisions” of types and elements because they can only be used when referenced through a namespace

NIEM is organized by namespace– NIEM-Core– Individual domains (Emergency Management, Immigration,

Intelligence, etc.)– Code table authorities (ATF, DEA, FBI, etc.)– External standards (ANSI/NIST, EDXL, TWPDES, etc.)– XSD proxy and constructs (niem-xsd, appinfo, structures)

NAMESPACES IN NIEM

Elements within NIEM are not allowed to be of an anonymous type and thus must be declared to be of a specific type; a defined structure for a data object

Specific types are derived from more generic types Type declarations determine the elements that can be contained within a

specific type and the order of those elements within the type All elements contained within a type must refer to a globally defined element

in the namespace Declared types can be:

TYPE DECLARATIONS IN NIEM

Complex Types with Complex Content

Child elements allowed, no character data

Complex Types with Simple Content

No child elements allowed, only character

data

Simple Types with Simple Content

No child elements or attributes allowed

There are no mixed types allowed in NIEMThe attribute mixed cannot equal true (mixed ≠ true)

Code lists are used to limit the possible values for a data element

CODE LISTS

Code lists:

Can be created using NIEM software tools based on values entered into a spreadsheet template

Can be integrated into a NIEM domain if identified as highly reusable by domain stewards

Can provide value through an increased level of data integrity and a decreased burden for management of code values

Possible Value

Possible Value

Possible Value

Code List

Data Element

Code lists are actively managed to make certain that they are accurate, current, and continue to follow the NIEM NDR

CODE LIST MANAGEMENT

Each code list has a governing body responsible for its content with authority over the timeline for updates and publication to the code list

Updates to published code lists within NIEM domains are often published in NIEM micro releases

Publication

Namespaces have been established within NIEM to contain related code lists and to designate authority over these code lists (e.g. iso, fips, twpdes, fbi, usps, etc.)

Namespace

Multiple versions of a code list may exist within NIEM to guarantee backward-compatibility

Version

Metadata types are used to provide descriptive information about data within an XML instance

METADATA TYPES WITHIN NIEM

nc:MetadataType contains several common elements used within exchange metadata. Some examples include:

•nc:LastUpdatedDate•nc:ReportingPersonText•nc:ExpirationDate

Often it is necessary to separate exchange data from auxiliary information that further describes the data; metadata types provide this level of separation

Metadata can be used for searching or categorizing data included within an exchange

DataMetadata

(e.g. Reported Date, Reporting Person)

WHY USE TYPE AUGMENTATION?

Why use Type Augmentation?– Each domain contains objects that other domains might need to

use– Adding these to an object would typically require making a

specialization– But, if objects are needed from multiple domains, then a

specialization doesn’t work– Cannot extend from multiple base objects

Augmentation is meant to solve this problem by allowing objects from multiple domains to be attached to an object

Augmentation objects explicitly show that data is just attached to an object without making a specialized version of the object

Augmentation types allow elements from multiple domains to be used in the definition of a new type

TYPE AUGMENTATION IN NIEM

Problem: XML Types are not allowed to extend from more than one base type– This limitation does not allow for elements from different domains to be

included within a single object through extension Problem Mitigation: Use augmentation types, each of which are

specific to a domain, to include elements from different domains to a new declared type

IntelligenceDomain

Elements

JusticeDomain

Elements

ImmigrationDomain

Elements

New Type

NIEM uses augmentations rather than specializations to support domain-specific properties

WHY SUBSTITUTION GROUPS?

Some types of information can be represented in multiple ways, for example:

‒ Enumerated Values‒ Date and Time‒ Many entities can be either a Person or an

Organization NIEM uses XML Schema Substitution Groups to allow a

single concept to be represented by multiple elements of different types

Substitution groups provide flexibility in the allowed data types for a particular element

SUBSTITUTION GROUPS IN NIEM

The data type for an element may not be known until runtime– Substitution groups address this problem by allowing elements of differing data

types to replace a declared element

Substitution groups provide for this flexibility in data representations For example:

– An entity can be represented by either a person or an organization– Criminal charges can be represented by either a number or a string value– Dates can be represented by either just the date or by date/time

Person Organization

Entity

Replaces Replaces

Explicit substitution forces substitution of an element for an abstract head element

Explicit substitution has the following characteristics:– Substitutable head elements are marked as

abstract=true– Abstract head elements act as placeholders for

substitute elements – Elements intended for substitution must identify the

abstract head element as its substitution group– Abstract head elements are NOT allowed to appear

within the XML instance

EXPLICIT SUBSTITUTION

Implied substitution provides flexibility in substitution by not requiring replacement of head element

Implied substitution has the following characteristics:– Substitutable head elements are NOT defined as abstract– May or may not be substituted– The element that is doing the substituting has to be of the

same type or derived type of the substitutable element – Substitutable head elements are allowed to appear within

the XML instance

IMPLIED SUBSTITUTION

NIEM UML PROFILEINTRODUCTION

NIEM UML PROFILE COMPONENTS

PIM PROFILE

THE GOALS FOR THE NIEM PIM PROFILE

• To represent the semantics of NIEM while being agnostic of its structural representation

• To leverage standards and standards based tools• To reduce complexity and lower the barrier for entry • To facilitate reuse of NIEM models and as a result

schemas• To embrace accepted UML modeling styles and

constructs• To enable use of NIEM-PIM models for use with other

standards, technologies and layers• To support deterministic mapping to and from the NIEM

technology layers based on NIEM rules

THE SCOPE OF THE NIEM PIM PROFILEUML Profiles for NIEM. A set of UML Profiles which provide a complete characterization of the semantics and information content embodied in NIEM. This is divided into two parts:

– The NIEM Vocabulary PIM – a profile for describing a business vocabulary in terms of NIEM concepts

– The NIEM MPD PIM – a profile for describing a MPD (i.e. an IEPD) that uses a NIEM vocabulary augmented with additional metadata to represent an MPD.

AUXILIARY TYPES AND MODEL LIBRARIES• NIEM Core Model Library – an isomorphic

representation of the NIEM reference namespaces• NIEM Primitive Types Model Library – represents the

NIEM primitive types leveraging the UML Library for XML Primitive Types

• Primitive Type Restrictions – uses a subset of the IMM-XSD profile to express constraints on primitive types

NIEM-UMLProfiles and Transforms

NIEM-UML Vocabularies

NIEM Vocabulary PIM Profile

NIEM MPD PIM Profile

Vocabulary Model For One or More Exchanges

Platform Independent Model of a Specific MPD

NIEM Core Vocabulary

NIEM Domain Vocabularies

Platform Specific Model of a Specific MPD

A NIEM MPD

NIEM PSM Profile

Existing NIEM NDR and MPD Platform Specifications

Extends &References

Uses

Uses

Includes

Maps Between

Transforms Between

XML Primitive Types

Uses

Conforms to

User’s UML

NIEM Models

Generated

Based onNIEM-UML

NIEM-UML

Model Libraries

Transform Specification

Mapping SpecificationConforms to

Conforms to

NIEM-UMLProfiles and Transforms

NIEM-UML Vocabularies

NIEM Vocabulary PIM Profile

NIEM MPD PIM Profile

Vocabulary Model For One or More Exchanges

Platform Independent Model of a Specific MPD

NIEM Core Vocabulary

NIEM Domain Vocabularies

Extends &References

Uses

UsesIncludes

XML Primitive Types

User’s UML

NIEM Models

NIEM-UML

Model Libraries

Platform Specific Model a NIEM Model in RDF

A NIEM RDF Schema

RDF Metamodel (ODM)

RDF/S

Maps Between

Uses

Conforms to

Transform Specification

Mapping SpecificationConforms to

Conforms toTransforms Between

Generated

Based onNIEM-UML

IntroduceRDF

Support

WHAT IS THE NIEM PIM PROFILE• A simplified subset of UML

• A set of UML constructs and stereotypes

– Extends UML to represent NIEM business concepts

– Business concepts are augmented with NIEM-Platform mapping information

– Enforces NIEM rules by leveraging OCL – a valid NEIM-UML model will produce a valid MPD

• Representations correspond to commonly used UML patterns with well defined mapping to NIEM platform

• Provides a generalized information modeling environment not specific to NIEM schema

• Supports mapping to and from the NIEM platform, supporting and enforcing the NDR and MPD

– E.g. name prefix and suffixes are added as specified by NIEM rules

UML SUBSET FOR THE NIEM PIM PROFILE

Metaclass

Packages

Classes, including their names (extended using NIEM stereotypes)

Associations and association classes (extended using NIEM stereotypes)

Association end, names, aggregation kind and cardinality (extended using NIEM stereotypes)

Properties (extended using NIEM stereotypes)

Data Types

Primitive Types

Realizations (extended using NIEM stereotypes)

Generalizations (extended using NIEM stereotypes)

Enumerations

Owned Comments

Dependencies (extended using NIEM stereotypes)

THE NIEM PIM VOCABULARY PROFILE

NIEM PROPERTIESNIEM Properties

Non-reference properties:Properties are represented as properties of UML classes or data types or as ends of associations. Information from the UML property or association end definition includes the name, type and cardinality..

NIEM PROPERTY REUSENIEM Property Reuse and Subset Schema

UML has no notion of properties independent of any class and the normal way to handle this in UML is to define classes, perhaps abstract, that are inherited. To be consistent with UML all properties are defined within a class (or data type). The <<References>> stereotype of realization is used to import properties from one class to another (perhaps in another name-space) to provide for the property reuse that is a principle of NIEM. The defining class can be complex type, an abstract type or a <<PropertyHolder>>. Property holders are a NIEM-PIM Stereotype specificity to hold properties not owned by a class in the namespace.

SUBSETTING A REFERENCE VOCABULARY

Subset for a particular exchange

Reference Vocabulary

NIEM SUBSTITUTION GROUPSNIEM Properties

A substitution group is represented by UML property subsetting. A property that subsets another will be substitutable for the base property. All subset properties within a name space are normally grouped together into a single class with the name of the base property combined with the suffix “SubstitutionGroup” (Current implementation is generating “PropertyHolder”). Substitution groups are also declared as a <<PropertyHolder>> since the containing class is not consequential, it is simple a holder for the group of substitutable properties.

NIEM PRIMITIVE TYPESNIEM Primitive Types

Primitive types are represented as a UML <<Primitive>>. There is a library of XSD data types included as part of the NIEM-PIM, this package is called “XMLPrimitiveTypes” (See Also: 0.2.4.2). Specialized primitive types may subclass this library to enable automatic mapping of the domain types to XML. The NIEM-Core provides a set of these types ready-made.XSD facets may be applied to primitive types to further constrain a representation. The PIM profile includes a set of stereotypes to represent these facets

REPRESENTATION OF COMPLEX TYPESNIEM Complex Type

Representation in the NIEM-PIM

Object Type

 Class or Data Type – no stereotype is required, Object Type is the default. See also: Representing NIEM Object Types

Role Type

 

Use of <<RoleOf>> association and or generalization referencing the complex signifies that type is a role. See Also:Representing NIEM Roles

Association Type

 

<<Association>> stereotype applied to the complex type or a UML association class. See Also: Representing NIEM Associations

Metadata Type

 

<<Metadata>> stereotype applied to the complex type. See Also: Representing NIEM Metadata

Augmentation Type

 

<<Augmentation>> stereotype applied to the complex type. See Also: Representing NIEM Augmentations

Adapter Type

 

<<Adapter>> stereotype applied to the complex type. The initial version of the PIM does not include adapter types, these will be added in the final specification.

NIEM OBJECT TYPESNIEM Object Types

An object type is represented as a UML class, no stereotype is required.

Alternative:A UML data type may also represent an Object Type.

YOUR BASIC “THING”<xsd:complexType name="PersonType">

<xsd:annotation>

<xsd:appinfo>

<i:Base i:name="Object" i:namespace="http://niem.gov/niem/structures/2.0"/>

</xsd:appinfo>

<xsd:documentation>A data type for a human being.</xsd:documentation>

</xsd:annotation>

<xsd:complexContent>

<xsd:extension base="s:ComplexObjectType">

<xsd:sequence>

<xsd:element maxOccurs="1" minOccurs="1" ref="nc:PersonBirthDate"/>

<xsd:element maxOccurs="1" minOccurs="1" ref="nc:PersonName"/>

<xsd:element maxOccurs="1" minOccurs="1" ref="nc:PersonSSNIdentification"/>

</xsd:sequence>

</xsd:extension>

</xsd:complexContent>

</xsd:complexType>

<xsd:element name="PersonBirthDate" nillable="false" type="nc:DateType">

<xsd:annotation>

<xsd:documentation>A date a person was born.</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name="PersonName" nillable="false" type="nc:PersonNameType">

<xsd:annotation>

<xsd:documentation>A combination of names and/or titles by which a person is known.</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name="PersonSSNIdentification" nillable="false" type="nc:IdentificationType">

<xsd:annotation>

<xsd:documentation>A unique reference to a living person; assigned by the United States Social Security Administration.</xsd:documentation>

</xsd:annotation>

</xsd:element>

Every element becomes global for

reuse (

Elements are used in XSD

data structures

NIEM ROLESNIEM Roles

UML also has the capability to represent roles in their simpler form as UML association ends (The names on the ends of lines in a class diagram) or properties. To represent roles that are complex types a class or data type is used.

NIEM Role Concept

NIEM ASSOCIATIONSNIEM Associations

A UML Class stereotyped as an <<Association>> represents a NIEM association using the rules of complex types. Each end of the NIEM association is represented as an independent UML association (an association line in a class diagram). The end is named on the related object side of the UML association and the cardinality of this relation will be the number of such objects that can participate in each association, this cardinality is usually one.

NIEM & UML ASSOCIATIONSNIEM Associations

Alternative:As UML includes a first-class concept of association classes, A NIEM association may also be represented as a UML association class (Line with a class attached by a dotted line), optionally having the <<Association>> stereotype.

NIEM CODE LISTSNIEM Code Types

Code types are represented as UML enumerations. Each code value is one value of the enumeration.

NIEM AUGMENTATIONS

• Alternative 1: A UML Data type may also represent an Augmentation Type

• Alternative 2: Generalizations marked as <<AugmentedBy>> will be mapped to a property with a cardinality of 1 to simulate multiple inheritance in the XSD.

NIEM Augmentations

An Augmentation type is represented as a UML class with the <<Augmentation>> Stereotype. A property typed by an augmentation type may have an <<AppliesTo>> dependency which restricts the class of objects that may contain a property typed by an augmentation (this is sometimes called the properties “domain”). Properties without an <<AppliesTo>> may be properties of any NIEM object.

NIEM METADATANIEM Metadata

A Metadata type is represented as a UML class with the <<Metadata>> Stereotype. A Metadata type may have an <<AppliesTo>> dependency which restricts the class of objects the metadata may be applied to. Metadata without an <<AppliesTo>> may be applied to any NIEM object.

THE NIEM PIM MPD PROFILE

EXAMPLE MPD

• Overlap with PSM• Further abstracting some concepts to be more

platform independent– Augmentations would be modeled differently in RDF– AppliesTo may overlap existing UML capabilities– Can substitution groups use regular subclassing?

• Better layering– Separation of true platform independent concepts from

those that are for support of mapping to/from MPDs

ISSUES TO BE ADDRESSED

PSM PROFILE

GOALS OF THE NIEM PSM PROFILE

• Clarity: Ensure that a UML representation of a NIEM model produced by one developer can be interpreted as expected by another.

• Completeness: Ensure that a developer can produce a UML representation of any NIEM concept, including semantics, XML Schema structure, and metadata.

• Practicality: With minimal effort, a developer can employ the profile in current UML development tools to develop a NIEM model.

64

65

UML SUBSET FOR NIEM SCHEMA

Metaclass

Package

DataType

Enumeration

EnumerationLiteral

Class

Property

Generalization

Dependency

A UML Profile consists of a subset of UML and a set of extensions to UML. The subset of UML used in the NIEM PSM Profile to represent NIEM-conforming XML Schemas consists of the above metaclasses.

66

OVERVIEW OF MAPPING TO NIEM SCHEMA

Metaclass Representation in NIEM-conforming XML Schema

Package schema document

DataType simple type definition

Enumeration simple type definition

EnumerationLiteral

enumeration facet

Class complex type definition

Property element or attribute declaration and use

Generalization derived type definition – base type definition relationship

Dependency other schema component relationship

The extensions to UML consist of a set of stereotypes that derive from this subset. In general, stereotypes extended from the metaclasses at left represent NIEM concepts implemented in XML Schema as specified at right.

CATEGORIZATION OF MAPPINGS TO NIEM SCHEMAStereotype (Metaclass)

NIEMNamespace (Package) Stereotype

NIEMNamespace

NIEMSimpleType (DataType, Enumeration) and Related Stereotypes

NIEMSimpleType NIEMCodeValue NIEMRestriction

NIEMListItemType NIEMUnionMemberType

NIEMComplexType (Class) and Related Stereotypes

NIEMComplexType NIEMAdapterType NIEMAssociationType

NIEMAugmentationType NIEMMetadataType NIEMObjectType

NIEMSimpleContent NIEMMetadataApplication

NIEMProperty (Property) and Related Stereotypes

NIEMProperty NIEMExternalProperty NIEMAnyProperty

NIEMTopLevel NIEMAugmentationApplication

NIEMChoice NIEMChoiceMemberProperty67

68

NIEMNAMESPACE STEREOTYPE

NIEMNamespace (Package)

• NIEMNamespace represents a namespace, which is implemented in XML Schema as an XML schema document.

• NIEMNamespace includes the following attributes: definition, isConformant, namespace, and version.

69

NIEMSIMPLETYPE AND RELATED STEREOTYPES

NIEMSimpleType (DataType) (can also be applied to Enumeration – next slide)

• NIEMSimpleType represents a NIEM type which is implemented in XML Schema as a simple type definition.

• NIEMSimpleType includes the following attributes: definition, fractionDigits, length, maxExclusive, maxInclusive, maxLength, minExclusive, minInclusive, minLength, pattern, totalDigits, and whiteSpace.

70

NIEMSIMPLETYPE AND RELATED STEREOTYPES

NIEMCodeValue (EnumerationLiteral)

• NIEMCodeValue represents a NIEM code value, which is implemented in XML Schema by an enumeration facet.

• NIEMCodeValue includes the following attributes: definition.

71

NIEMSIMPLETYPE AND RELATED STEREOTYPES

Stereotype (Generalization) Relationship

NIEMRestriction (Generalization) from a derived (by restriction) typeto its base type definition

NIEMListItemType (Dependency) from a list simple type definitionto its item type definition

NIEMUnionMemberType (Dependency)

from a union simple type definitionto one of its member type definitions

72

NIEMCOMPLEXTYPE AND RELATED STEREOTYPES

NIEMComplexType (Class),NIEMAdapterType (NIEMComplexType),NIEMAssociationType (NIEMComplexType), NIEMAugmentationType (NIEMComplexType), NIEMMetadataType (NIEMComplexType),NIEMObjectType (NIEMComplexType)

• NIEMComplexType is the generalization of the other stereotypes.• NIEMAdapterType, NIEMAssociationType, NIEMAugmentationType,

NIEMMetadataType, and NIEMObjectType represent the given class of NIEM type; these are implemented in XML Schema as complex type definitions.

• Stereotypes include the following attributes: definition.

73

NIEMCOMPLEXTYPE AND RELATED STEREOTYPES

Stereotype (Generalization) Relationship

Generalization from an derived (by extension) typeto its base complex type definition

NIEMSimpleContent (Dependency) from a complex type definitionto its simple content type

NIEMMetadataApplication (Dependency)

from a metadata type definitionto the type definition it applies to

74

NIEMPROPERTY AND RELATED STEREOTYPES

NIEMProperty (Property)

• NIEMProperty represents a NIEM property, which is implemented in XML Schema as an element or attribute declaration and use.

• NIEMProperty includes the following attributes: definition, kind, nillable, namespace, substitutionGroupName, substitutionGroupNamespace, value.

75

NIEMPROPERTY AND RELATED STEREOTYPES

NIEMExternalProperty (Property)

• NIEMExternalProperty represents an external component, which is implemented in XML Schema as an element or attribute use.

• NIEMExternalProperty includes the following attributes: kind, namespace.

76

NIEMPROPERTY AND RELATED STEREOTYPES

NIEMAnyProperty (Property)

• NIEMAnyProperty represents the use of a wildcard, which is implemented in XML Schema as the xsd:any particle.

• Stereotype includes the following attributes: definition, namespace, processContents.

77

NIEMPROPERTY AND RELATED STEREOTYPES

NIEMTopLevel (Class)

• NIEMTopLevel does not represent any NIEM concept; it exists to permit the user to define a NIEM property that is not the subject of any NIEM type.

78

NIEMPROPERTY AND RELATED STEREOTYPES

NIEMChoice (Property)

• NIEMChoice represents the use of a choice model group in XML Schema.• NIEMChoice includes the following attributes: definition.

79

NIEMPROPERTY AND RELATED STEREOTYPES

Stereotype (Generalization) Relationship

NIEMAugmentationApplication (Dependency)

from an augmentation elementto the type definition it applies to

NIEMChoiceMemberProperty (Dependency)

from a choice groupto its member element

NIEM NUMBERED RELEASESREFERENCE SCHEMAS

Reference Schemas

INFORMATION EXCHANGE PACKAGE DOCUMENTATION (IEPD)

Subset (of 2.1)

ncfbi

cbrn

mda

itatf

hazmatappinfo

structures

Extension Set

ext1

ext2

ext4

ext3

ExchangeSchema

my_iepd

Constraint Set (of 2.1 ss)

ncfbi

cbrn

mda

itatf

hazmatappinfo

structures

catalog.xml

changelog.xml

master-document.doc

http://my.org/iepd/my-iepd-1.4/d

eriv

ed

-fro

m

der

ive

d--

fro

m

importsim

po

rts

my_iepd.xml

82

UML SUBSET FOR MPD

Metaclass

Package

Dependency

A UML Profile consists of a subset of UML and a set of extensions to UML. The subset of UML used in the NIEM PSM Profile to represent MPDs consists of the above metaclasses.

83

OVERVIEW OF MAPPING TO MPDS

UML Metaclass MPD

Package MPD or XML schema

Dependency MPD-MPD, MPD-XML schema relationships

The extensions to UML consist of a set of stereotypes that derive from this subset. In general, stereotypes extended from the metaclasses at left represent NIEM concepts implemented in MPDs as specified at right.

84

MODELPACKAGEDESCRIPTION AND RELATED STEREOTYPES

ModelPackageDescription (Package)

• ModelPackageDescription represents a Model Package Description (MPD). Specifically, it represents the information in the catalog.

Stereotype (Generalization) Relationship

ModelPackageDescriptionRelationship (Dependency)

from an MPDto the MPD to which it is related

ModelPackageDescriptionFile (Dependency)

from an MPDto the NIEMNamespace it includes

MODELPACKAGEDESCRIPTION AND RELATED STEREOTYPES

85

ADDITIONAL EXAMPLE (NIEMSIMPLETYPE)

86

ADDITIONAL EXAMPLE (NIEMLISTITEMTYPE)

87

ADDITIONAL EXAMPLE (NIEMUNIONMEMBERTYPE)

88

ADDITIONAL EXAMPLE (NIEMCODEVALUE)

89

ADDITIONAL EXAMPLE (NIEMOBJECTTYPE)

90

ADDITIONAL EXAMPLE (NIEMSIMPLECONTENT)

91

ADDITIONAL EXAMPLE (NIEMMETADATAAPPLICATION)

92

NEXT STEPS AND WAY FORWARD

• Significant overlap between the PIM and the PSM due to similar goals

• Profile complexity due to the two similar models

• Lack of a profile which is an isomorphic representation of an NIEM IEPD

• Potential challenges with transformations between the PIM and the PSM and between the PSM and an IEPD

Challenges with Current Approach

Candidate Profile Architecture for Validation

UML Profile For NIEMUML Profile For NIEM

UML subset and NIEM semantic stereotypes

NIEM representational stereotypes

MPD XSD ArtifactsMPD XSD Artifacts

Isomorphic mapping

XSD representational stereotypes

The profile presents a continuum

from a level of abstraction perspective

Ad

din

g stereo

typesA

dd

ing

fea

ture

s

Entry Point for NIEM Business Modelers

Entry Point for NIEM Schema Modelers

Defau

lts

• Validate the proposed submission architecture: – Perform gap analysis between the overlapping PIM

and PSM concepts – Work together on defining a representation for the

overlapping constructs which defer in representation– Identify where in the profile each of the current PIM

and PSM concepts belongs

• As soon as consensus is reached, work together to implement and document each concept.

• Assemble the final submission

Next Steps

OBJECTIVES OF COMBINED PROFILE

• Standards Based: To leverage standards and standards based tools

• Simplicity: To reduce complexity and lower the barrier for entry

• Reuse: To facilitate reuse of NIEM models and as a result schemas

• Agility: To enable the NIEM profile to be used with other standards,

technologies and layers

• Audience: Two entry points for tools and modelers – business and schema

• Clarity: Ensure that a UML representation of a NIEM model produced by one

developer can be interpreted as expected by another.

• Completeness: Ensure that a developer can produce a UML representation

of any NIEM concept, including semantics, XML Schema structure, and

metadata.

• Practicality: With minimal effort, a developer can employ the profile in

current UML development tools to develop a NIEM model.

QUESTIONS ???