260 likes | 372 Views
Model Driven Standards. November 2009 Work Group Meeting Presented By Galen Mulrooney, J P Systems Sean Muir, JKM Software. Background: Modeling. Models are representations of something to be built in the real world The model lets one visualize what will be built before it’s built
E N D
Model Driven Standards November 2009 Work Group Meeting Presented By Galen Mulrooney, J P Systems Sean Muir, JKM Software
Background: Modeling • Models are representations of something to be built in the real world • The model lets one visualize what will be built before it’s built • The model is easier and cheaper to build and change than the real thing
Background: Modeling • Models are used in many industries • Manufacturers build models of automobiles, aircraft, etc. before building • Perhaps the most useful analogy is a set of blueprints for a building • Different blueprints are built for different viewpoints, or specialties • Plumbing blueprint and electrical blueprint are two specialized views of the same building • Both use standardized notations specific to the specialty. Any trained plumber should be able to read and understand any plumbing blueprint
Software Modeling • Modeling in software is as old as software itself • Modeling notations, techniques, and tools have become increasingly rich • In part because the software they are designed to model becomes more complex • Most modeling techniques / tools can generate software • The quality / usefulness of such generated software is greatly improved over earlier generations of software modeling techniques
Software Modeling • The industry standard modeling language is the Unified Modeling Language (UML) • UML is primarily designed to support Object Oriented Analysis and Design • All modern development languages are Object Oriented (e.g., Java, C++, Delphi, Visual Basic.net)
Software Modeling • UML is actually a language in and of itself • It has specific syntax and semantics • It has defined icons which help visualize the model, but the language behind the diagrams is what’s important • Like architectural blueprints, there are multiple views (diagram types) to be used for different purposes, or specialties • There are some 30 model types • Nobody uses them all. Only the largest of projects will use more than a dozen or so • The most widely used (and useful) model type is the Class Model
Benefits of Modeling • Ensures that developers have a consistent understanding of the components of the system • Ensures that software components are properly re-used • E.g., if a “Person” class is already defined, why create a totally different one? Besides efficiencies, other developers would be confused as to which one to use when • Models can be validated by subject matter experts who are not programmers • It’s easier to validate a picture than it is to validate a bunch of Java code • Subject Matter Experts can be easily trained to interpret the model – they don’t need to know the target programming language
UML Transformed to Other Languages Class Diagram XML Schema Definition Java <xs:element name="PatientIdentity" type="VaIdentity" substitutionGroup="personIdentity" /> - <xs:complexType name="PatientIdentity"> - <xs:complexContent> - <xs:extension base="PersonIdentity"> - <xs:sequence> - <xs:element name="administrativeGender" type="AdministrativeGenderCode"> - <xs:annotation> <xs:documentation>A value representing the gender (sex) of a person. The allowable values for this field as specified by the DS DAT for Demographics are: F (Female), M (Male) and UN (unspecified).</xs:documentation> </xs:annotation> ... public interface PatientIdentity extends personSRDTs.PersonIdentity { livingSubject.AdministrativeGenderCode getAdministrativeGender(); void setAdministrativeGender(livingSubject.AdministrativeGenderCode administrativeGender); livingSubject.AdministrativeGenderCode addNewAdministrativeGender(); livingSubject.BirthTime getDateOfBirth(); void setDateOfBirth(livingSubject.BirthTime dateOfBirth); livingSubject.BirthTime addNewDateOfBirth(); ...
MDA Transforms to Other Models Conceptual Model (CIM) Model to Model Transformations Payload PSM Database PSM Java Object PSM Model to Implementation Transformations Database Java Application Payload
What MDA does NOT mean to NCPDP? Everyone does NOT need to become a UML or modeling expert NCPDP does NOT need to change the way it currently does business
What DOES MDA mean to NCPDP? The NCPDP standards will be expressed and maintained internally as a series of UML models Current and future required artifacts needed to support NCPDP business/standards process will be generated either completely or in part from the NCPDP model itself
Some Benefits to NCPDP • Ensure consistency between Standards • Person in SCRIPT and Person in Telecom should be identical (or at least subsets of some common thing) • This makes both standards easier to implement by NCPDP members • The same software component used to generate / receive a Person in an outgoing / incoming SCRIPT message can be used for Telecom too
Some Benefits to NCPDP • There is value in the model itself • NCPDP members can use the models to generate software components • Ensures consistency between implementations – less left to chance based on programmer’s interpretations of the Implementation Guides • Conformance testing can be automated
Some Benefits to NCPDP • Release Process can be Automated • Faster Release Artifacts • Consistent Release Artifacts (eg EDI/XML) • Generate Version Deltas • Standard’s Implementation • Generated NCPDP Messaging Tools • Message Widget • Software Components • Delta Models
Standards ImplementationMessage Widget Before MDA After MDA Share a Message Widget
Standard’s ImplementationSoftware Components Standards Body Development Team Standards currently released as documents which are then interpreted by the implementing organization.
Standard’s ImplementationSoftware Components Standards Body Development Team Generate software components that help the development teams manage change
Standard’s ImplementationDelta Models Script Version 15 Script Version 17 15-16 16-17 17-18 17-18 15-18 Script Version 18
MDA Simple Example Add a New Value to ECL Generate new ECL Report Generate new XSD Generate new Java code
What we’re doing • Reverse-engineering NCPDP Standards (starting with SCRIPT 10.6) into UML • Creating a generic “Domain Analysis Model” (DAM, aka Conceptual Information Model [CIM]) from the concepts found • Forward-engineering (aka “generating”) Implementation Guides from the Model (both EDI and XML) • Laying the groundwork for NCPDP to move into Service Specification development • In short, we’re moving to “Model-Driven Standards” development
What We Have (so far) Supports ECL generation Supports XSD generation based on current model Supports ECL process Supports draft version of NCPDP for CDA Supports draft code generation for NCPDP support for XML and EDI Private OHT Project Development Site Established
MDS Next Steps Validate Domain Analysis Model Reverse Engineer Another Standard (e.g. Telecom) Begin Service Specification Work (e.g. Return Credit)
References • UML • http://www.uml.org • Open Health Tools • http://www.openhealthtools.org/ • Eclipse Modeling Project • http://www.eclipse.org/modeling/ • NCPDP Modeling WIKI • http://ncpdpmodeling.wikispaces.com/