NIEM UML

Report
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
Creation
of the
standardized
exchange
• Selection based on number of stakeholders and
potential for reuse
• Complexity increases with numbers of entities involved
• Benefit increases with numbers of implementations
Governance
and adoption
of the
exchange
WHAT IS NIEM –
THE NIEM
FRAMEWORK
AND PROCESS
THE NIEM FRAMEWORK
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.
Community
Technical Framework
Support Framework
Formal Governance Processes
Data Model
Tools for Development
and Discovery
Online Repositories
XML Design Rules
Established
Training Program
Mission-Oriented Domains
Development Methodology
Implementation Support
Self-Managing
Domain Stewards
Predefined
Deliverables (IEPD)
Help Desk &
Knowledge Center
STANDARDIZING DATA MOVING
ACROSS SYSTEMS
COMMONLY
FORMATTED
DATA
I N T E R FA C E
LEGACY
DATABASES
I N T E R FA C E
Scope-of-NIEM
LEGACY
DATABASES
Translation
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.
THE NIEM DATA MODEL
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.
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
THE NIEM LIFECYCLES
Common Language
Repeatable, Reusable Process
(Data Model Lifecycle)
(Exchange Specification Lifecycle)
Built and governed by the business users at
Federal, State, Local, Tribal and Private Sectors
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
IEPD MPD
IEPD IEM
Main Document
Catalog
Change Log
Sample XML Instance
<Exchange_Schema/>
<Extension_Schema/>
<Subset_Schema/>
NIEM Core
Schema(s)
Domain
Schema(s)
In order to be NIEM-conformant, the IEPD
must adhere to:
1.
2.
3.
NIEM Conformance Document
NIEM Naming and Design Rules (NDR) v1.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)
ESC
Executive Steering Council
NIEM PMO
Executive Director
Deputy Director
NC&OC
NTAC
NBAC
NIEM Communications &
Outreach Committee
NIEM Technical
Architecture Committee
NIEM Business
Architecture Committee
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: Model Package
MPD/IEM
Description
 IEM: Information
Exchange Model
IEPD
Domain
Update
Release
EIEM/BIEC
 EIEM: Enterprise
Information Exchange
Model
 BIEC: Business
Information Exchange
Component
IEM VS. MPD
Information Exchange Model
(IEM)
Model Package Description
(MPD)
•
•
•
One or more NIEM-conforming
XML schemas that specify the
structure, semantics, and
relationships of XML objects
IEM Classes:
–
–
–
–
Compressed archive of files that
contains:
–
–
–
One and only one of the four NIEM IEM
classes
Supporting documentation
Other artifacts
Release
Domain Update
Information Exchange Package Documentation
(IEPD)
Enterprise Information Exchange Model (EIEM)
IEPD MPD
IEPD IEM
<Exchange_Schema/>
<Extension_Schema/>
IEPD IEM
Main Document
Catalog
<Subset_Schema/>
<Exchange_Schema/>
<Extension_Schema/>
<Subset_Schema/>
Change Log
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 SELFSERVICE
Domain Independence
Domain Self-Service
• 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
• 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
Domain Update MPD
Domain Update IEM
Catalog
<Reference_Schema/>
Change Log
Quality Assurance/Conformance
Reports
In order to be NIEM-conformant, the Domain
Update must adhere to:
1.
2.
3.
4.
NIEM Conformance Document
NIEM Naming and Design Rules (NDR) v1.3
NIEM Domain Update Specification v1.0
NIEM Model Package Description (MPD) Specification v1.0
WHY NAMESPACES?
 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
Namespaces allow for modification of parts of NIEM without impact on
the rest of the model
NAMESPACES IN NIEM
 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)
TYPE DECLARATIONS 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:
Complex Types with
Complex Content
Complex Types with
Simple Content
Simple Types with
Simple Content
Child elements allowed,
no character data
No child elements
allowed, only character
data
No child elements or
attributes allowed
There are no mixed types allowed in NIEM
The attribute mixed cannot equal true (mixed ≠ true)
CODE LISTS
Code lists are used to limit the possible values for a data element
Possible
Value
Data Element
Possible
Value
Possible
Value
Code lists:
Code List
 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
CODE LIST MANAGEMENT
Code lists are actively managed to make certain that they
are accurate, current, and continue to follow the NIEM NDR
Publication
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
Namespace
Version
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.)
Multiple versions of a code list
may exist within NIEM to
guarantee backwardcompatibility
METADATA TYPES WITHIN NIEM
Metadata types are used to provide descriptive information about data
within an XML instance
Metadata
Data
(e.g. Reported Date,
Reporting Person)
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
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
TYPE AUGMENTATION IN NIEM
Augmentation types allow elements from multiple domains to be used
in the definition of a new type
New Type
Immigration
Domain
Elements
Intelligence
Domain
Elements
Justice
Domain
Elements
 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
NIEM uses augmentations rather than specializations to support domainspecific 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 IN NIEM
Substitution groups provide flexibility in the allowed data types for a
particular element
Entity
Person
Organization
 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
EXPLICIT SUBSTITUTION
 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
IMPLIED 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
NIEM UML PROFILE
INTRODUCTION
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 PROFILE
UML 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-UML Vocabularies
XML Primitive
Types
NIEM Vocabulary PIM
Profile
Uses
NIEM Domain
Vocabularies
NIEM Core
Vocabulary
NIEM-UML
Model Libraries
Extends &
References
Vocabulary Model For One
or More Exchanges
NIEM-UML
Profiles and Transforms
Includes
NIEM MPD PIM Profile
Transform Specification
NIEM PSM Profile
Mapping Specification
Existing NIEM NDR and
MPD Platform Specifications
Uses
Conforms to
Uses
Conforms to
User’s UML
NIEM Models
Platform Independent Model
of a Specific MPD
Transforms Between
Platform Specific Model of a
Specific MPD
Generated
Maps Between
Conforms to
A NIEM MPD
Based on
NIEM-UML
NIEM-UML Vocabularies
XML Primitive
Types
NIEM Vocabulary PIM
Profile
Uses
NIEM Domain
Vocabularies
NIEM Core
Vocabulary
NIEM-UML
Model Libraries
Extends &
References
Vocabulary Model For One
or More Exchanges
NIEM-UML
Profiles and Transforms
Includes
Uses
NIEM MPD PIM Profile
Transform Specification
RDF Metamodel (ODM)
Mapping Specification
RDF/S
Conforms to
Uses
Conforms to
User’s UML
NIEM Models
Platform Independent Model
of a Specific MPD
Transforms Between
Platform Specific Model a
NIEM Model in RDF
Introduce
RDF
Support
Generated
Maps Between
Conforms to
A NIEM RDF Schema
Based on
NIEM-UML
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 PROPERTIES
NIEM 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 REUSE
NIEM 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 GROUPS
NIEM 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 TYPES
NIEM 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 TYPES
NIEM 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 TYPES
NIEM 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">
Elements are
used in XSD
data
structures
Every element
becomes
global for
reuse (
NIEM ROLES
NIEM 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 ASSOCIATIONS
NIEM 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 ASSOCIATIONS
NIEM 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 LISTS
NIEM Code Types
Code types are represented as UML enumerations. Each code value is one
value of the enumeration.
NIEM AUGMENTATIONS
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.
• 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 METADATA
NIEM 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
ISSUES TO BE ADDRESSED
• 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
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
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.
65
OVERVIEW OF MAPPING TO NIEM SCHEMA
Metaclass
Representation in NIEM-conforming XML Schema
Package
schema document
DataType
simple type definition
Enumeration
simple type definition
EnumerationLiter
al
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.
66
CATEGORIZATION OF MAPPINGS TO NIEM
SCHEMA
Stereotype (Metaclass)
NIEMNamespace (Package) Stereotype
NIEMNamespace
NIEMSimpleType (DataType, Enumeration) and Related Stereotypes
NIEMSimpleType
NIEMCodeValue
NIEMListItemType
NIEMUnionMemberType
NIEMRestriction
NIEMComplexType (Class) and Related Stereotypes
NIEMComplexType
NIEMAdapterType
NIEMAssociationType
NIEMAugmentationType
NIEMMetadataType
NIEMObjectType
NIEMSimpleContent
NIEMMetadataApplication
NIEMProperty (Property) and Related Stereotypes
NIEMProperty
NIEMExternalProperty
NIEMAnyProperty
NIEMTopLevel
NIEMAugmentationApplication
NIEMChoice
67
NIEMChoiceMemberProperty
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.
68
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.
69
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.
70
NIEMSIMPLETYPE AND RELATED STEREOTYPES
Stereotype (Generalization)
Relationship
NIEMRestriction (Generalization)
from a derived (by restriction) type
to its base type definition
NIEMListItemType (Dependency)
from a list simple type definition
to its item type definition
NIEMUnionMemberType
(Dependency)
from a union simple type definition
to one of its member type definitions
71
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.
72
NIEMCOMPLEXTYPE AND RELATED STEREOTYPES
Stereotype (Generalization)
Relationship
Generalization
from an derived (by extension) type
to its base complex type definition
NIEMSimpleContent (Dependency)
from a complex type definition
to its simple content type
NIEMMetadataApplication
(Dependency)
from a metadata type definition
to the type definition it applies to
73
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.
74
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.
75
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.
76
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.
77
NIEMPROPERTY AND RELATED STEREOTYPES
NIEMChoice (Property)
• NIEMChoice represents the use of a choice model group in XML Schema.
• NIEMChoice includes the following attributes: definition.
78
NIEMPROPERTY AND RELATED STEREOTYPES
Stereotype (Generalization)
Relationship
NIEMAugmentationApplication
(Dependency)
from an augmentation element
to the type definition it applies to
NIEMChoiceMemberProperty
(Dependency)
from a choice group
to its member element
79
NIEM NUMBERED RELEASES
REFERENCE SCHEMAS
Reference Schemas
INFORMATION EXCHANGE PACKAGE
DOCUMENTATION (IEPD)
md
it
a
hazma
t
appinf
es
o
Subset (of 2.1)
derived--from
cbr
nc
nat
fb
istructur
f
imports
ext
ext
1
2
ext
ext
3
4
Extension
Set
imports
derived-from
http://my.org/iepd/my-iepd-1.4/
my_iep
d
Exchange
Schema
cbr
nc
nat
fb
istructur
f
md
it
a
hazma
t
appinf
es
o 2.1
Constraint
Set (of
ss)
catalog.xml
changelog.x
ml
masterdocument.doc
my_iepd.xml
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.
82
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.
83
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 from an MPD
(Dependency)
to the MPD to which it is related
ModelPackageDescriptionFile
(Dependency)
84
from an MPD
to 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
Challenges with Current Approach
• 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
Candidate Profile Architecture for Validation
Defaults
Adding stereotypes
Adding features
UML Profile For NIEM
UML subset and NIEM
semantic stereotypes
Entry Point for NIEM Business Modelers
NIEM representational
stereotypes
XSD representational
stereotypes
Isomorphic mapping
MPD XSD Artifacts
Entry Point for NIEM Schema Modelers
The profile
presents a
continuum
from a level of
abstraction
perspective
Next Steps
• 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
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 ???

similar documents