case studies on information exchange package documentation iepd development l.
Skip this Video
Loading SlideShow in 5 Seconds..
Case Studies on Information Exchange Package Documentation (IEPD) Development PowerPoint Presentation
Download Presentation
Case Studies on Information Exchange Package Documentation (IEPD) Development

Loading in 2 Seconds...

play fullscreen
1 / 36

Case Studies on Information Exchange Package Documentation (IEPD) Development - PowerPoint PPT Presentation

  • Uploaded on

Case Studies on Information Exchange Package Documentation (IEPD) Development GJXDM Users Conference Atlanta, Georgia June 9, 2005 IEPD Goals and Objectives Define IEPDs ( Information Exchange Package Documentation ) to support interoperability among justice systems

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Case Studies on Information Exchange Package Documentation (IEPD) Development' - niveditha

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
case studies on information exchange package documentation iepd development

Case Studies on Information Exchange Package Documentation (IEPD) Development

GJXDM Users Conference

Atlanta, Georgia

June 9, 2005

iepd goals and objectives
IEPD Goals and Objectives
  • Define IEPDs (Information Exchange Package Documentation) to support interoperability among justice systems
  • Expand and refine GJXDM/DD through experienced feedback; resolve vague definitions
  • Constrain/restrict down to key choices to support interoperability
goals of the iepd process
Goals of the IEPD Process
  • More consistent development of GJXDM conformant schemas
  • Produce artifacts that help project stakeholders
  • Provides a mechanism to synthesize domain/business knowledge of SMEs
  • Supports artifact reuse
  • Leverages open standards
  • Works with standards based tools that are readily available in the public domain
  • Shares lessons learned/best practices
iepds developed 2004 2005
IEPDs Developed 2004-2005
  • Sentencing Order
  • Amber Alert
  • Field Interview Report
  • Charging Document
  • Incident Reporting
  • Uniform Rap Sheet
  • Booking/Arrest Report
iepd business issues
IEPD Business Issues
  • Business goals are the primary driver
  • Participation by business representatives
  • IEP built upon use case
  • Justice exchange data does not belong to only one domain
    • Example: Protection from Abuse Order
  • GJXDM conformance
  • Reuse of artifacts
  • Every IEP is a potential model
iepd workgroup
IEPD Workgroup
  • Representative group of exchange partners
  • Inclusion of business SMEs and technical experts
  • Selection of members is important
  • Consensus process
  • IEPs cannot be built by technical staff or business staff in isolation, partnership is critical
  • Skilled, experienced facilitator important
workgroup facilitator skills
Workgroup: Facilitator skills
  • Organization and project management
  • Neutrality
  • Understanding of the domain
  • Understanding of IEPD process
  • Understanding of domain modeling
    • UML
    • Object-oriented design
  • Understanding of GJXDM
  • Awareness of national reference material
workgroup sme member skills
Workgroup: SME member skills
  • Understanding of business processes
    • Triggering and subsequent processes
    • Required content
    • Relationships
  • Ability to describe the semantic meaning of the data
  • Ability to “think outside the box”
    • As-is processes versus to-be processes
    • Openness to change semantic concepts to align with GJXDM
workgroup tech member skills
Workgroup: Tech member skills
  • Understanding of GJXDM
    • Source of good ideas for domain model
    • Think ahead to mapping
  • Understanding of data availability and needs at exchange endpoints
  • Understanding of basic domain modeling concepts (including O/O design)
project planning
Project planning
  • Obviously, depends on the document
  • Rough guidelines:
    • Domain modeling (face-to-face, 2-3 days)
    • Mapping (face-to-face for 1-2 days, another 1-2 days remote)
    • Schema building (facilitator or tech member(s) only, 2-3 days)
    • Packaging (1 day)
iepd process
IEPD Process
  • JIEM/Exchange Requirements
  • Domain Modeling
  • GJXDM Mapping
  • Subset Schema (SSGT)
  • Extension, Document, Constraint
  • Sample XML Instance
  • Packaging
  • Horizontal Analysis/Reuse
  • Education and Outreach
incident reporting iepd
Incident Reporting IEPD
  • Project funded by COPS Office
  • Participants:
    • Local Law Enforcement
    • State Law Enforcement
      • NIBRS, UCR, Repository
    • FBI
    • Prosecution
    • Statistical Crime Reporting
domain modeling motivation
Domain Modeling: Motivation
  • In building an IEP, it is very helpful to have:
    • A precise definition/description of document structure
    • A description that can be understandable and verifiable by all stakeholders (bridge the communication gap)
    • A description technique that facilitates interactive design
domain modeling uml

Precise and formal, yet…

Graphical and understandable by stakeholders

Supports O/O concepts inherent in XML Schema

Supported by low-cost tools

Industry/developer buy-in and adoption

Domain Modeling: UML
domain modeling uml17

Need to educate stakeholders about notation

Learning curve for modeler (learning notation)

Can lock into tools if you’re not careful

Domain Modeling: UML
domain modeling associations
Domain Modeling: Associations
  • Associations describe how the classes relate to one another
  • Example: A police officer issues a citation
  • Can be verbs from the domain, or simply descriptions of relationships
  • When modeling hierarchical document structures, associations are navigable (uni-directional)
  • Associations indicated with open-ended arrows
  • Can be named; if not, read as “relates to,” “contains,” or “has”
gjxdm as source of domain concepts
GJXDM as source of domain concepts
  • XSTF has already done a lot of good thinking about concepts in the justice domain
  • GJXDM contains 400 nouns (complex types)
  • Use these if they fit…don’t reinvent the wheel
  • Don’t use them if they don’t fit…don’t restrict your domain model to what’s in GJXDM
  • Remember: need to build a model that the business people can understand and agree to
  • Most business people struggle to validate structures documented in schema
mapping to gjxdm
Mapping to GJXDM
  • To build schema, each class/property in the domain model must be mapped to a type/element in GJXDM
  • Sometimes mapping can be represented in path-like notation
  • Sometimes it can only be described in prose
  • Makes automated mapping (and schemas generated from the domain model) very difficult
  • Sometimes domain concepts are missing from GJXDM; these are mapped to elements in an extension schema (your own namespace)
mapping to gjxdm22
Mapping to GJXDM
  • Spreadsheet with four columns:
    • Class
    • Property or Association
    • GJXDM Mapping (path or prose, extensions color-coded)
    • Notes
gjxdm mapping incident report
GJXDM Mapping: Incident Report
  • Incident Report Mapping
  • Subset Schema
  • Constraint Schema
  • Extension Schema
  • Document Schema
  • Sample XML Instance
  • IEPD
  • Wide tool support for UML
    • Visio
    • Eclipse plug-ins
    • ArgoUML
    • Rational Rose and XDE
  • Keep in mind that the primary purpose of a domain model is communication.
  • Many people beyond you (and your IT department) will be reading the model, so it has to be accessible to them using tools they already have (or can acquire cheaply).
  • XML Metadata Interchange standard
  • Evolved by the Object Management Group (OMG)
  • XML representation of object-oriented models
  • Useful for custom reporting from the data in your model
  • Does not contain information about the graphics
  • XMI allows generic metadata to be stored along with the entities in your model
  • Metadata can then be extracted and reported
  • Use ordinary XML technologies for reporting
    • SAX, DOM parsing
    • XML-object binding
    • XSLT
  • Example: documenting information sources and reporting with XSLT
lessons learned
Lessons Learned
  • Facilitation is critical
  • Can be successful in bringing together business and technical experts
  • Iterative process
  • Domain modeling can accelerate the development process
  • For most domain structures GJXDM is a good fit, Exceptions: Associations
  • Project completed with low cost open tools
  • Information Exchange Package Documentation Guidelines
  • Process Overview whitepaper (by, adopted by IJIS XML Advisory Committee)
  • Example IEPDs
  • Domain-Driven Design, by Eric Evans
  • UML Distilled, by Martin Fowler
  • Analysis Patterns, by Martin Fowler
  • Modeling XML Applications with UML, by David Carlson
  • Object-Oriented Design Heuristics, by Arthur Riel
iepd goals and objectives34
IEPD Goals and Objectives
  • Remember: the goal is to exchange messages, not to build databases
  • The more we standardize the container and the payload of components, the more it supports our goals
  • Standard, non-proprietary, consistently structured artifacts helps all of us to leverage IEPDs as models for information sharing
thank you
Thank you!
  • Catherine Plummer
  • Scott Came
  • Jeff Harmon
case studies on information exchange package documentation iepd development36

Case Studies on Information Exchange Package Documentation (IEPD) Development

GJXDM Users Conference

Atlanta, Georgia

June 9, 2005