1 / 98

NIEM UML Profile Initial Submission

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. Selection based on number of stakeholders and potential for reuse

marshall-garrett
Download Presentation

NIEM UML Profile Initial Submission

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. NIEM UML Profile Initial Submission

  2. Agenda NIEM Overview NIEM Technical Concepts NIEM UML Profile Introduction PIM Profile PSM Profile Next Steps and Way Forward

  3. The NIEM FORMULA FOR SUCCESS • Selection based on number of stakeholders andpotential for reuse • Complexity increases with numbers of entities involved • Benefit increases with numbers of implementations

  4. What is NIEM – The NIEM Framework and Process

  5. 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 Established Training Program Online Repositories XML Design Rules Mission-Oriented Domains Implementation Support Development Methodology Predefined Deliverables (IEPD) Self-Managing Domain Stewards Help Desk & Knowledge Center

  6. Standardizing Data Moving Across Systems Scope-of-NIEM COMMONLY FORMATTED DATA INTERFACE INTERFACE LEGACY DATABASES 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.

  7. 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

  8. The NIEM LIFECYCLES Common Language(Data Model Lifecycle) Repeatable, Reusable Process (Exchange Specification Lifecycle) Built and governed by the business users at Federal, State, Local, Tribal and Private Sectors

  9. 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

  10. IEPD Components & Requirements IEPD MPD IEPD IEM Main Document <Exchange_Schema/> In order to be NIEM-conformant, the IEPD must adhere to: • NIEM Conformance Document • NIEM Naming and Design Rules (NDR) v1.3 • NIEM Model Package Description (MPD) Specification v1.0 Catalog <Extension_Schema/> <Subset_Schema/> Change Log Domain Schema(s) NIEM Core Schema(s) Sample XML Instance

  11. NIEM Governance

  12. NIEM Governing Structure 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 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)

  13. 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)

  14. 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.

  15. NIEM technical concepts

  16. NIEM Conformance

  17. NIEM Model Packages

  18. NIEM Model Packages • MPD: Model Package Description • IEM: Information Exchange Model • EIEM: Enterprise Information Exchange Model • BIEC: Business Information Exchange Component

  19. IEM vs. MPD Information 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 IEPD MPD IEPD IEM IEPD IEM <Exchange_Schema/> <Exchange_Schema/> Main Document <Extension_Schema/> <Extension_Schema/> Catalog <Subset_Schema/> <Subset_Schema/> Change Log

  20. 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

  21. Domain Independence and Self-Service

  22. Domain Update Components & Requirements Domain Update MPD Domain Update IEM <Reference_Schema/> Catalog Change Log Quality Assurance/Conformance Reports In order to be NIEM-conformant, the Domain Update must adhere to: 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

  23. 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

  24. 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)

  25. 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)

  26. Code Lists Code lists are used to limit the possiblevalues for a data element Possible Value Possible Value Data Element Possible Value 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 Code List

  27. 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 backward-compatibility

  28. Metadata Types within NIEM Metadata types are used to provide descriptive information about data within an XML instance Data Metadata (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

  29. 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

  30. Type Augmentation in NIEM Augmentation types allow elements from multiple domains to be used in the definition of a new type New Type ImmigrationDomain Elements IntelligenceDomain Elements JusticeDomain 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 domain-specific properties

  31. 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

  32. Substitution Groups in NIEM Substitution groups provide flexibility in the allowed data types for a particular element Entity Replaces Person Organization Replaces • 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

  33. 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

  34. 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

  35. NIEM UML ProfileIntroduction

  36. NIEM UML Profile Components

  37. PIM Profile

  38. 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

  39. 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.

  40. 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

  41. NIEM-UML Vocabularies XML Primitive Types NIEM-UML Model Libraries NIEM-UML Profiles and Transforms Uses NIEM Vocabulary PIM Profile NIEM Core Vocabulary NIEM Domain Vocabularies Extends & References Vocabulary Model For One or More Exchanges User’s UML NIEM Models Includes NIEM MPD PIM Profile Uses Platform Independent Model of a Specific MPD Conforms to Transforms Between Transform Specification Uses NIEM PSM Profile Platform Specific Model of a Specific MPD Generated Based on NIEM-UML Conforms to Maps Between Mapping Specification Conforms to Existing NIEM NDR and MPD Platform Specifications A NIEM MPD

  42. NIEM-UML Vocabularies XML Primitive Types NIEM-UML Model Libraries NIEM-UML Profiles and Transforms Uses NIEM Vocabulary PIM Profile NIEM Core Vocabulary NIEM Domain Vocabularies Extends & References Vocabulary Model For One or More Exchanges User’s UML NIEM Models Includes Uses NIEM MPD PIM Profile Platform Independent Model of a Specific MPD Introduce RDF Support Conforms to Transforms Between Transform Specification Uses RDF Metamodel (ODM) Platform Specific Model a NIEM Model in RDF Generated Based on NIEM-UML Conforms to Maps Between Mapping Specification Conforms to RDF/S A NIEM RDF Schema

  43. 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

  44. UML Subset for the NIEM PIM Profile

  45. The NIEM PIM Vocabulary Profile

  46. NIEM Properties

  47. NIEM Property Reuse

  48. Subsetting a Reference Vocabulary Reference Vocabulary Subset for a particular exchange

  49. NIEM Substitution Groups

  50. NIEM Primitive Types

More Related