ATIS 0410100-0003-2008 Unified Modeling Approach (UMA)- Guiding Principles.pdf

1、ATIS-0410100-0003 UMA Committee Issued 12/12/2007 Guiding Principles Page 1 of 24 ATIS-0410100-0003 Unified Modeling Approach (UMA) Committees Guiding Principles Issue 3 ATIS-0410100-0003 UMA Committee Issued 12/12/2007 Guiding Principles Page 2 of 24 ATIS is a technical planning and standards devel

2、opment organization that is committed to rapidly developing and promoting technical and operations standards for the communications and related information technologies industry worldwide using a pragmatic, flexible and open approach. Over 1,100 participants from more than 350 communications compani

3、es are active in ATIS 23 industry committees, and the ATIS Incubator Solutions Program. www.atis.org ATIS 0410100-0003 Unified Modeling Approach (UMA)Guiding Principles Is an ATIS standard developed by the following committee(s) under the ATIS Ordering and Billing Functional Group: Ordering and Bill

4、ing Forum UMA Published by ATIS 1200 G Street, NW, Suite 500 Washington, DC 20005 Copyright 2007 by Alliance for Telecommunications Industry Solutions All rights reserved. No part of this publication may be reproduced in any form, in an electronic retrieval system or otherwise, without the prior wri

5、tten permission of the publisher. For information contact ATIS at 202.628.6380. ATIS is online at . Printed in the United States of America. ATIS-0410100-0003 UMA Committee Issued 12/12/2007 Guiding Principles Page 3 of 24 Notice of Disclaimer and Limitation of Liability The information provided in

6、this document is directed solely to professionals who have the appropriate degree of experience to understand and interpret its contents in accordance with generally accepted engineering or other professional standards and applicable regulations. No recommendation as to products or vendors is made o

7、r should be implied. NO REPRESENTATION OR WARRANTY IS MADE THAT THE INFORMATION IS TECHNICALLY ACCURATE OR SUFFICIENT OR CONFORMS TO ANY STATUTE, GOVERNMENTAL RULE OR REGULATION, AND FURTHER, NO REPRESENTATION OR WARRANTY IS MADE OF MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE OR AGAINST IN

8、FRINGEMENT OF INTELLECTUAL PROPERTY RIGHTS. ATIS SHALL NOT BE LIABLE, BEYOND THE AMOUNT OF ANY SUM RECEIVED IN PAYMENT BY ATIS FOR THIS DOCUMENT, WITH RESPECT TO ANY CLAIM, AND IN NO EVENT SHALL ATIS BE LIABLE FOR LOST PROFITS OR OTHER INCIDENTAL OR CONSEQUENTIAL DAMAGES. ATIS EXPRESSLY ADVISES ANY

9、AND ALL USE OF OR RELIANCE UPON THIS INFORMATION PROVIDED IN THIS DOCUMENT IS AT THE RISK OF THE USER. ATIS-0410100-0003 UMA Committee Issued 12/12/2007 Guiding Principles Page 4 of 24 HISTORY LOG Version Date Issuer Reason 1 6/8/2006 UMA Committee Initial Publication 2 09/24/2007 UMA Committee Revi

10、sion to include GOE Approach 3 12/12/2007 UMA Committee Revision to add recommended pattern for Namespace ATIS-0410100-0003 UMA Committee Issued 12/12/2007 Guiding Principles Page 5 of 24 HISTORY LOG .4 1 INTRODUCTION7 1.1 NEED.7 1.2 AUDIENCE.7 1.3 SCOPE .7 1.4 MANAGEMENT OF THIS DOCUMENT .7 2 PROCE

11、SS DESCRIPTION UMA APPLICATION DEVELOPMENT 8 3 UMA DEVELOPMENT APPROACH.9 3.1 USE OBF INDUSTRY PRACTICES9 3.2 DEVELOP AN INFORMATION MODEL.9 3.3 SEPARATE BUSINESS DATA FROM PROCESSING DATA 9 3.4 FLEXIBLE SCHEMA DEFINITIONS .10 3.5 SCHEMA DESIGN PATTERNS .10 4 RECOMMENDED UMA APPLICATION FRAMEWORK11

12、4.1 UMA APPLICATIONS SHOULD FOLLOW TML FRAMEWORK AND W3C GUIDELINES 11 4.2 XML SCHEMAS SHOULD SUPPORT VERSIONING .11 4.3 UTILIZE TML TRANSPORT PROFILE11 4.4 UTILIZE THE XSL:INCLUDE INSTRUCTION IN SCHEMAS 12 4.5 UTILIZE UOM-BASE SCHEMA12 4.6 UTILIZE BUSINESS DOCUMENT NAMING FOR TAGS.12 4.7 MAXIMUM LE

13、NGTH FOR TAG NAMES.13 4.8 USE OF MAX OCCURRENCES13 4.9 DO NOT INCLUDE PREPRINTED SEPARATORS WHEN DEFINING MAXLENGTH.13 4.10 UTILIZE EXTENSIBILITY BASED ON CURRENT INTERFACE RULES AND BASED ON SECTION WITHIN UOM VOLUME IV14 4.11 RESOLUTION OF DATA DEFINITION DIFFERENCES (E.G. USE, SEMANTICS, NAME, MA

14、X LENGTH) .14 5 XML FEATURE RECOMMENDATIONS 15 5.1 GENERAL NAMING CONVENTIONS15 5.2 STRING IS THE PREFERRED DATA TYPE.15 5.3 USE OF CHARACTER ENCODING.15 5.4 USE OF DEFAULT ELEMENT AND ATTRIBUTE FORMS16 5.5 ABSENCE OF DATA AND RELATED CONSIDERATIONS 16 5.6 ELEMENTS VS. ATTRIBUTES16 5.7 PROCESSING IN

15、STRUCTIONS .17 5.8 ELEMENT NILLABILITY VS. MINOCCURS=0.17 5.9 ABSTRACT TYPES .18 5.10 USE OF COMPLEX TYPES AND SIMPLE TYPES.18 5.11 AVOID USE OF XML GROUPS 18 5.12 AVOID USE OF SUBSTITUTION GROUPS 19 5.13 AVOID USE OF GROUP REDEFINITION.19 5.14 LOCAL VS. GLOBAL DECLARATIONS.19 5.15 USE OF DEFAULT/FI

16、XED VALUES .20 5.16 ANNOTATIONS .20 5.17 NOTATIONS .20 5.18 DOCUMENTATION ELEMENT .21 ATIS-0410100-0003 UMA Committee Issued 12/12/2007 Guiding Principles Page 6 of 24 5.19 NAMESPACES21 5.20 ALL VS. SEQUENCE22 5.21 DATE AND TIME TYPES23 6 REFERENCES 24 ATIS-0410100-0003 UMA Committee Issued 12/12/20

17、07 Guiding Principles Page 7 of 24 1 INTRODUCTION 1.1 Need This document will provide a guideline which will enable the development of interoperable XML messaging based interfaces within the Unified Modeling Approach (UMA) domain. Since it is often difficult to get started with a complex schema desi

18、gn, especially when there is no previous experience, this document provides recommendations, benefits, disadvantages and rationale made by existing UMA applications. The underlying goal is to avoid having each UMA sub-team rediscover certain design considerations through costly trial and error. 1.2

19、Audience This document targets individuals working on ATIS UMA initiatives, or other architects and software engineers who develop new or enhance existing UMA XML based interfaces. These Guiding Principles assume that the reader already has a working knowledge of W3C XML Schema recommendations and h

20、as a working knowledge of XML and XML-based messaging interface design. Also a general assumption is made that the reader understands the current ATIS TOPS initiatives related to UMA and to some extent, the existing OBF application domains. 1.3 Scope The scope of this document covers recommended XML

21、 schema features within the industry. It should be reviewed, along with associated reference material, prior to beginning work on any new UMA application and during modifications of existing UMA applications. The recommendations within this document are the result of lessons learned and conversation

22、s between various UMA committees, and are not a comprehensive analysis of XML features/functionality. 1.4 Management of this Document This document is intended to be common across the various UMA committees. Since each committee may identify opportunities for enhancing this guide, changes need to be

23、 discussed at a cross-committee level. It is recommended that each UMA committee review any impacting design decisions and facilitate a cross-committee discussion to approve document improvements. If variations to the Guiding Principles are necessary to support a specific UMA application, difference

24、s should be documented within the Generic Implementation Guideline (GIG) or via appendix. ATIS-0410100-0003 UMA Committee Issued 12/12/2007 Guiding Principles Page 8 of 24 2 PROCESS DESCRIPTION UMA APPLICATION DEVELOPMENT Whenever a new UMA committee is formed, the following process will help to org

25、anize the committee and integrate them among the other UMA committee efforts. 1. Identify and recruit resources who have technical background in UML modeling and XML schema design. 2. Become familiar with recommended UML modeling and XML schema design tools. (Rational Rose versus Argo, XMLSpy, Eclip

26、se, HyperModel, etc.) 3. Review already published “common” UMA documents and information, created by any existing UMA committee efforts. (Existing UOM deliverables (Volumes I-IV), UMA Guiding Principles, Generic Implementation Guideline (Volume IV), UOM-BASE schemas, etc.) to leverage synergies from

27、 previous implementations. 4. Committee members should familiarize themselves with the various schema paradigms like Garden of Eden, Venetian Blind, Salami Slice 5. Review and familiarize the team with UMA development approaches. (Use cases, logical data modeling, schema design and definition, etc.)

28、 6. Begin development effort for your committee. 7. As development progresses for a given UMA application, significant design concerns should be discussed across the UMA committees. As a result, the following may occur: o Guiding Principles may be updated o Issues may be initiated to various UMA com

29、mittees for review and/or inclusion o Issues may be referred to other OBF committees for review and/or inclusion o Originating UMA committee may choose to vary from the Guiding Principles. When this is decided, those variances should be documented separately. ATIS-0410100-0003 UMA Committee Issued 1

30、2/12/2007 Guiding Principles Page 9 of 24 3 UMA DEVELOPMENT APPROACH 3.1 Use OBF Industry Practices Recommendation: Use appropriate OBF documentation (e.g. LSOG, ASOG, WICIS). Create a Business Requirements document (Volume I) if necessary, based on the appropriate OBF documentation. Description: Us

31、e OBF Industry Practices (e.g., LSOG for UOM-LSR, ASOG for UOM-ASR) Benefits: Data models and interfaces should be developed in conjunction with existing business and application processes to allow for migration and support interoperability Use of existing industry practices will save time and impro

32、ve implementation consistency Prevents rework and encourages reuse 3.2 Develop an Information Model Recommendation: The development of a protocol neutral Information Model will serve as a common analysis tool that benefits business process teams and development groups. The model should follow the cu

33、rrent Unified Modeling Language (UML) Specification. The specification is available via the Object Management Group (OMG) at: http:/www.omg.org/technology/documents/formal/uml.htm. Description: A protocol neutral Information Model should be defined (e.g. Volume II UOM-#) using UML. Benefits: A data

34、model may be used to generate the XML schema set to ensure that there is consistency in the use of data element definitions as some data elements repeat, (e.g., data elements repeat across forms on an LSR firm order request) Appropriate analysis will allow for interoperability with existing implemen

35、tations Use of previously defined Information Model Packages and data elements will save time and improve consistency across domains 3.3 Separate Business Data from Processing Data Recommendation: Segmenting the data allows for the greatest interoperability with existing architecture/systems, thus a

36、llowing a single process solution regardless of protocol. Description: Processing data should be placed in the header and business data should be placed in the body of the schema. When defining Information Model and Schemas, data related to the processing and transport of transactions should be kept

37、 separate from the business information being transported. Benefits: Isolates maintenance requirements between transport processing and business rules validation Approach supports existing interoperability Minimizes industry standard interface updates ATIS-0410100-0003 UMA Committee Issued 12/12/200

38、7 Guiding Principles Page 10 of 24 3.4 Flexible Schema Definitions Recommendation: Limit the use of required within the interfaceby leaving the interface “loose,” applications can manage the interface based on existing software solutions. Critical requirements may be enforced at the Gateway/Parser l

39、evel. This will support interoperability and minimize Gateway work. Key items to be considered should be type, maximum length and nulls should be managed in the schema. Generally business rules should be enforced in separate applications. Beyond the header and existing administrative fields all othe

40、r data elements should be represented as optional. Description: The definition of data element requirements (Required, Conditional, Optional) and data type (e.g. string) should remain loose enough to support end architecture. In contrast however, key application elements or elements that drive proce

41、ssing should be tightly defined. Benefits: Key data is caught up-front to identify critical items Provides the widest range of interoperability between business processes Minimizes industry standard interface updates Supports internal OSSs business rules validation and associated error handling proc

42、esses Allows company specific business requirements to be processed in industry standard schemas Allows data to be passed and handled via previously defined error handling processes on both ends of the interface Focus on Gateway edits rather than business or backend OSS edits Disadvantages: Does not

43、 take advantage of all dimensions of XML Allows invalid data to flow into backend OSSs 3.5 Schema Design Patterns Recommendation: Overall design of the application schemas should follow the Garden of Eden approach Description: There are several acceptable design patterns within the industry for deve

44、loping XML schemas. These include Garden of Eden, Venetian Blind, Salami Slice, Russian Doll, and Bologna. The UML committees have adopted an approach for developing their XML schemas which most resembles the Garden of Eden approach. All elements and types are defined in the global namespace with th

45、e elements referenced as needed. This solution supports the defining of simple types () as well as directly defining individual elements () which are referenced () in your schema. Benefits: Allows reuse of both elements and types Allows multiple files Disadvantages: Leads to a more verbose schema Co

46、ntains many potential root elements Limits encapsulation by exposing types ATIS-0410100-0003 UMA Committee Issued 12/12/2007 Guiding Principles Page 11 of 24 4 RECOMMENDED UMA APPLICATION FRAMEWORK 4.1 UMA Applications Should Follow tML Framework and W3C Guidelines Recommendation: Follow W3C and tML Framework and document variations when necessary. Include variations in either this document or within individual UOM application varia