1 / 36

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 Define IEPDs ( Information Exchange Package Documentation ) to support interoperability among justice systems

niveditha
Download Presentation

Case Studies on Information Exchange Package Documentation (IEPD) Development

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. Case Studies on Information Exchange Package Documentation (IEPD) Development GJXDM Users Conference Atlanta, Georgia June 9, 2005

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

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

  4. IEPDs Developed 2004-2005 • Sentencing Order • Amber Alert • Field Interview Report • Charging Document • Incident Reporting • Uniform Rap Sheet • Booking/Arrest Report

  5. Information Exchange Package Documentation Process

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

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

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

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

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

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

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

  13. Incident Reporting IEPD • Project funded by COPS Office • Participants: • Local Law Enforcement • State Law Enforcement • NIBRS, UCR, Repository • FBI • Prosecution • Statistical Crime Reporting

  14. Domain Modeling: Incident Report

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

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

  17. Cons Need to educate stakeholders about notation Learning curve for modeler (learning notation) Can lock into tools if you’re not careful Domain Modeling: UML

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

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

  20. Domain Modeling: Incident Report

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

  22. Mapping to GJXDM • Spreadsheet with four columns: • Class • Property or Association • GJXDM Mapping (path or prose, extensions color-coded) • Notes

  23. GJXDM Mapping: Incident Report • Incident Report Mapping

  24. SSGT Want List

  25. SSGT Want List

  26. Packaging • Subset Schema • Constraint Schema • Extension Schema • Document Schema • Sample XML Instance • IEPD

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

  28. XMI • 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

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

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

  31. Resources • Information Exchange Package Documentation Guidelines • Process Overview whitepaper (by justiceintegration.com, adopted by IJIS XML Advisory Committee) • Example IEPDs

  32. Resources • 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

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

  34. Thank you! • Catherine Plummer • catherine.plummer@search.org • Scott Came • scott@justiceintegration.com • Jeff Harmon • JeffreyHarmon@maximus.com

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

More Related