Case Studies on Information Exchange Package Documentation (IEPD) Development GJXDM Users Conference Atlanta, Georgia June 9, 2005.

Case Studies on Information Exchange Package Documentation (IEPD) Development

GJXDM Users ConferenceAtlanta, Georgia

June 9, 2005

2004 SEARCH, The National Consortium for Justice Information and Statistics | www.search.org

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

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

Sentencing Order Amber Alert Field Interview Report Charging Document Incident Reporting Uniform Rap Sheet Booking/Arrest Report


Information Exchange Package Documentation Process


IEPD Business Issues

Business goals are the primary driverParticipation by business representativesIEP built upon use caseJustice exchange data does not belong

to only one domain Example: Protection from Abuse Order

GJXDM conformanceReuse of artifactsEvery IEP is a potential model


IEPD Workgroup

Representative group of exchange partners

Inclusion of business SMEs and technical experts

Selection of members is importantConsensus process IEPs cannot be built by technical staff or

business staff in isolation, partnership is critical

Skilled, experienced facilitator important


Workgroup: Facilitator skills

Organization and project managementNeutralityUnderstanding of the domainUnderstanding of IEPD processUnderstanding of domain modeling

UML Object-oriented design

Understanding of GJXDM Awareness of national reference

material


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

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

Obviously, depends on the documentRough 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

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

Project funded by COPS OfficeParticipants:

Local Law Enforcement State Law Enforcement

NIBRS, UCR, Repository FBI Prosecution Statistical Crime Reporting


Domain Modeling: Incident Report


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

Pros 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

Cons Need to educate

stakeholders about notation

Learning curve for modeler (learning notation)

Can lock into tools if you’re not careful


Domain Modeling: Associations

Associations describe how the classes relate to one another

Example: A police officer issues a citationCan be verbs from the domain, or simply

descriptions of relationshipsWhen modeling hierarchical document

structures, associations are navigable (uni-directional)

Associations indicated with open-ended arrowsCan be named; if not, read as “relates to,”

“contains,” or “has”


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 wheelDon’t use them if they don’t fit…don’t restrict

your domain model to what’s in GJXDMRemember: need to build a model that the

business people can understand and agree toMost business people struggle to validate

structures documented in schema


Domain Modeling: Incident Report


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 proseMakes 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 GJXDM

Spreadsheet with four columns: Class Property or Association GJXDM Mapping (path or prose,

extensions color-coded) Notes


GJXDM Mapping: Incident Report

Incident Report Mapping



SSGT Want List


SSGT Want List


Packaging

Subset Schema Constraint Schema Extension Schema Document Schema Sample XML Instance IEPD


Tools

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


XMI

XML Metadata Interchange standardEvolved by the Object Management Group

(OMG)XML representation of object-oriented modelsUseful for custom reporting from the data in

your modelDoes not contain information about the

graphicsXMI allows generic metadata to be stored along

with the entities in your model


XMI

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

Facilitation is criticalCan be successful in bringing together

business and technical expertsIterative processDomain modeling can accelerate the

development processFor most domain structures GJXDM is a

good fit, Exceptions: AssociationsProject completed with low cost open

tools


Resources

Information Exchange Package Documentation Guidelines

Process Overview whitepaper (by justiceintegration.com, adopted by IJIS XML Advisory Committee)

Example IEPDs


Resources

Domain-Driven Design, by Eric EvansUML Distilled, by Martin FowlerAnalysis Patterns, by Martin FowlerModeling XML Applications with UML,

by David CarlsonObject-Oriented Design Heuristics, by

Arthur Riel


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!

Catherine [email protected]

Scott [email protected]

Jeff [email protected]

Case Studies on Information Exchange Package Documentation (IEPD) Development

GJXDM Users ConferenceAtlanta, Georgia

June 9, 2005

Case Studies on Information Exchange Package Documentation (IEPD) Development GJXDM Users Conference Atlanta, Georgia June 9, 2005.

Documents

justice information

national consortium

gjxdm slide

justice systems

interoperability slide

business processes

iepd goals

use case justice exchange