m2ap- methodology for message assembly profile: improving

Accessibility: FREE Special mention: Declassification: Front page of 53 DRAFT ©EDF

EDF R&D MEASUREMENTS AND INFORMATION SYSTEMS OF ELECTRICAL NETWORKS (MIRE)

INTEROPERABILITE ET APPLICATIONS METIERS

1 avenue du Général de Gaulle - 92141 CLAMART CEDEX, +33 (1) 47 65 43 21

Department certified ISO 9001 : 2000

Page de garde

M2AP- Methodology for Message Assembly Profile: Improving traceability, reusability and instance interoperability in CIM XML message content schema

design : proposal based on UN/Cefact Core Component work

Cyril EFFANTIN [email protected]

Jean-Luc SANSON [email protected]

H-R49-2006-04284-EN Draft Version: 0.4 Date: 28 November 2006

The goal of this document is to provide guide lines to facilitate XML data exchange between applications of the electrotechnical domain. Its main focus is to insure reusability, traceability and instance interoperability in CIM XML Message schema design. Nowadays, IT designers found that a shared semantic facilitates interoperability between applications. That is why working groups such as IEC (International Electrotechnical Commission) are building Information Model (like the IEC Common Information Model), that describes data and its associated semantic that can be exchanged in a specific business domain. UML (Universal Modeling Language) is the language used to model data and express this semantic, and XML is the preferred syntax to exchange data by means of message content. So, rules and methods, defining how to map UML to XML Message Content and how to preserve semantic in the mapping, must be defined. Right now, UN/Cefact (United Nations/Centre for Trade Facilitation and Electronic Business) and partly IEC through their "XML Naming and Design rules", are making an important work on this subject. However, UN/Cefact work is still in progress, and there are some missing parts at Message Assembly level and XML NDR that needs to be filled. This document is a study to see how UN/Cefact works could be applied to IEC TC 57 needs for XML Message Exchange based on the IEC Common Information Model. The results of this study are presented here and ended with some proposals to make CIM more compliant with UN/Cefact Core Components works and to enhance and expend UN/Cefact specifications. In attachment, you will find some examples of XML schemas corresponding to the definition of XML messages following the rules described in this document.

mailto:[email protected]

mailto:[email protected]

Accessibility: FREE Special mention: Declassification: Front page of 53 DRAFT ©EDF

Front Page

Diffusion list

Recipient Department / Structure Diffusion

LEFEBVRE Thierry RTE [email protected] MARTIN Dan Xtensible Solutions [email protected] ROBINSON Greg Xtensible Solutions [email protected] WANG Xiaofeng Xtensible Solutions [email protected] ZHOU Joe Xtensible Solutions [email protected] SAXTON Terry Xtensible Solutions [email protected] NEUMANN Scott Uisol [email protected] HAYNES David Twacs [email protected] GILLERMAN John SISCO [email protected] CLEVELAND Frances Xanthus Consulting International [email protected] TAYLOR Don Actaris [email protected] DEVOS Arnold Langdale Consultants [email protected] KOSTIC Tatjana ABB [email protected] SNYDER Aaron ITRON [email protected] MCMORRAN Alan University of Strathclyde [email protected] MACQUEEN Chris Syntegra [email protected] BAH Thierno Hydro Quebec [email protected] CHANZY Emmanuel Areva [email protected] ANTILA Erkki ABB [email protected] BOARDMAN Ethan Areva [email protected] SUTER Gilbert Siemens [email protected] SEDDON Greville GNDS [email protected] TRACEY Jim Generale Electrique [email protected] WAIGHT Jim Siemens [email protected] HARTZFELD Kimberly Accenture [email protected] Lars-Ola ABB [email protected] COFFEY Michael Letsys [email protected] DANIELS Mike Miner [email protected] KUMAR Navaneet Elster [email protected] REIDEL Peter ABB [email protected] PREVOST Jacques Ireq [email protected] THURLBY Robert BT [email protected] WALLACE Ron MRO [email protected] HOFFMAN Roy Slecs [email protected] ANSAR Shahed Central-Networks Shahed.Ansar@central-

networks.co.uk KIKKAWA Shigetaka SCE [email protected] AMSBARY Stephan HP [email protected] SHEN Theresa Cellnet [email protected] SKARE Paul Siemens [email protected] BERRY Tom Schneider [email protected]

electric.com ADRIAENSEN Maurice Kema [email protected] CVETKOVIC Aleksandar Syseca [email protected] MARIE Benoit Areva [email protected] SCHMITT Laurent Areva [email protected] BECKER Dave Epri [email protected] DIEHL Hans-Joachim Siemens [email protected] BRITTON Jay Areva [email protected] WUERGLER Erich Siemens [email protected] DOBROWOLSKI Edward Nerc [email protected] HUNTER Kurt Siemens [email protected] ARIURA Yoshio Toshiba [email protected] TANAKA Tatsuji Toshiba [email protected] YAMAOKA Kazuo Jpower [email protected]

EDF R&D

M2AP- Methodology for Message Assembly Profile: Improving traceability, reusability and instance interoperability in CIM XML message content schema design : proposal based on UN/Cefact Core Component work

H-R49-2006-04284-EN

Accessibility : FREE sur 53 DRAFT ©EDF

Executive Summary In order to increase interoperability between applications, the EDF R&D project called CIMERGY has developed a UML modeling methodology (Unified Modeling Language) and XML Schema Design based on UN/Cefact (United Nations/Centre for Trade Facilitation and Electronic Business) works: CCTS (Core Component Technical Specification) and XML NDR (Naming and Design Rules). The goal of this methodology is to provide a guide for designing XML (eXtensible Markup Language) messages schemas sharing a semantic modeled into a UML Information Model.

In this approach, UN/Cefact specifications want to:

• Give a conceptual definition of each require element of the methodology (CCTS)

• Give a UML meta-model extensions profile to endorse those conceptual elements into the UML world in order to establish the behavior of UML tools supporting UN/Cefact approach (BCSS Business Collaboration Schema Specification).

• Give all the rules for XML schemas (XSD) generation (XML NDR)

The complete set of specifications is not finished: it should be completed by two other specifications : “Message Assembly”, which will give rules to assemble components in a Message Content Architecture, and “Unified Context Methodology”, which will define Context and attach usage rules.

Rigth now, XML NDR is not complete because it lacks some rules needed for Message Assembly. So in order to be able to use the UN/Cefact works in XML Schema design, CIMERGY project made some enhancements to complete these works, and implement them on some real business use case studies.

IEC (International Electrotechnical Commission) TC57 workgroups are thinking about adopting those UN/Cefact recommendations, that are also by the way becoming ISO standards. Right now, IEC is specifying an adaptation of the UN/Cefact XML NDR in order to give recommendations for designing XML messages sharing the CIM semantic (IEC UML Model for the whole electricity domain standing for Common Information Model). So, as EDF R&D is both member of IEC TC 57 and UN/Cefact, results of its works will serve as basis input to these two organizations.

The goal of this document is not to present the UN/Cefact XML NDR but to propose solutions for the new “Message Assembly” specifications and enhance “XML NDR” in order to have a good XML Content Message Schema Design. Especially this document shows some solutions that insure also reusability, traceability and instance interoperability at XML level too and not only at UML level.

At the same time, this document will help us to exchange EDF R&D ideas with IEC TC 57 working groups that are adapting UN/Cefact recommendations for IEC business studies.

After having quickly presented those recommendations, this document will present an EDF R&D XML Message Content Design Rules, taking the CIM as the Information Model and then applying the UN/Cefact derivation process. It is based on a small business example extracted from a real EDF business use case.

The results of this UN/Cefact derivation process lead us to make some proposals to enhance UN/Cefact actual specifications and some contributions to the next ones. They also gave us another vision of what should be CIM modeling and how to make it more UN/Cefact compliant. This first attempt to apply UN/Cefact specifications on the CIM and IEC works needs to be completed, because it is based on our interpretation of CCTS and our UML Profile.

But still as it is, the main conclusion is that UN/Cefact methodology, even if it needs some complements, is a good way to go to generate XML Schemas based on a shared semantic. At both UML and XML level, Message description could be done with different profiles, according to needed functionalities. Here, where our target was reusability, traceability and instance interoperability, we ended up with a profile that meets all these requirements: but this is achieved with some complexity at the XML Schema side.

Note: in order to fully understand this document some knowledge of IEC TC 57 standards (61968 and 61970) and UN/Cefact CCTS is necessary.

EDF R&D


H-R49-2006-04284-EN


Summary

PAGE DE GARDE ...................................................................................................................................1

FRONT PAGE ..........................................................................................................................................2

DIFFUSION LIST .....................................................................................................................................2

EXECUTIVE SUMMARY..........................................................................................................................3

SUMMARY ...............................................................................................................................................4

1. REFERENCE DOCUMENTS ........................................................................................................6

2. OVERVIEW ...................................................................................................................................6

3. WHAT WAS THE TRIGGER OF THIS STUDY? ..........................................................................6 3.1. CIM: THE IEC TC 57 COMMON INFORMATION MODEL .......................................................................6 3.2. IEC TC 57 MESSAGE EXCHANGE .....................................................................................................9 4. UN/CEFACT CORE COMPONENT METHODOLOGY ..............................................................10 4.1. CCTS ...........................................................................................................................................10 4.2. CCTS METHODOLOGY PROPOSED EVOLUTION ................................................................................11

4.2.1. Introduction...........................................................................................................................11 4.2.2. Basic CCTS proposed evolution ..........................................................................................12 4.2.3. Full CCTS proposed evolution .............................................................................................13

4.3. UN/CEFACT MAIN SPECIFICATIONS..................................................................................................13 4.4. MESSAGE ASSEMBLY NEEDS..........................................................................................................14

4.4.1. Message Assembly Architecture ..........................................................................................15 4.4.2. ABIE Assembly.....................................................................................................................15

4.4.2.1. Sequencing Assembly ................................................................................................................16 4.4.2.2. Traceability .................................................................................................................................16 4.4.2.3. Instance Interoperability..............................................................................................................17 4.4.2.4. Properties grouping ....................................................................................................................18 4.4.2.5. Assembly Rules Profiles .............................................................................................................18

4.5. XSD DESIGN NEEDS.......................................................................................................................19 4.5.1. Introduction...........................................................................................................................19 4.5.2. Some details about instance interoperability at XSD level...................................................20

5. EXAMPLE BASED ON AN ADAPTATION OF UN/CEFACT METHODOLOGY.......................23 5.1. DESCRIPTION OF THE BUSINESS EXAMPLE .......................................................................................23 5.2. UML MODELING FOR THIS BUSINESS EXAMPLE.................................................................................23

5.2.1. UML Information Model (Core Components Model) ............................................................23 5.2.1.1. CIM generic Model......................................................................................................................23 5.2.1.2. Extensions of the UML information model ..................................................................................24 5.2.1.3. Associations................................................................................................................................24 5.2.1.4. Association Class .......................................................................................................................25

5.2.2. UML Contextual Model (Business Information Entities) for our business domain ...............25 5.2.2.1. Selection of required information model UML objects.................................................................25 5.2.2.2. Restrictions of Information Model selected Objects ....................................................................27 5.2.2.3. Contextual Association Class .....................................................................................................29

5.2.3. UML Message sub-Contextual Model ..................................................................................31 5.2.4. UML Message Assembly Model...........................................................................................32

5.2.4.1. UML Message Assembly Model profile without instance interoperability....................................32 5.2.4.2. UML Message Assembly Model Profile with instance interoperability ........................................32

6. IMPLEMENTATION MESSAGE: PROPOSAL FOR XML SCHEMAS GENERATION .............34

EDF R&D


H-R49-2006-04284-EN


6.1. GENERAL XSD RULES ...................................................................................................................34 6.2. IMPLEMENTATION MESSAGE MODEL (XSD) GENERATION RULES ......................................................36

6.2.1. Modularity Presentation........................................................................................................36 6.2.2. UML Information Model to XSD............................................................................................37 6.2.3. UML Information Model Extensions to XSD.........................................................................38 6.2.4. UML (Sub-)Contextual Model to XSD ..................................................................................38 6.2.5. UML Message Assembly Model to XSD ..............................................................................40

6.2.5.1. profile (without instance interoperability) to XSD ........................................................................40 6.2.5.2. Instance interoperability profile to XSD.......................................................................................41

6.2.5.2.1. Basic XSD generation for Elements and types .......................................................................41 6.2.5.2.2. How to deal with ABIE being an association class?................................................................43 6.2.5.2.3. Full Instance Interoperability XSD generation for our example ...............................................44

7. CONSEQUENCES ON IMPROVING TRACEABILITY, REUSABILITY AND INSTANCE INTEROPERABILITY.............................................................................................................................45 7.1. TRACEABILITY................................................................................................................................45 7.2. REUSABILITY..................................................................................................................................45 7.3. INSTANCE INTEROPERABILITY .........................................................................................................47 8. CONCLUSIONS ..........................................................................................................................48 8.1. MAIN CONCLUSIONS .......................................................................................................................48 8.2. SOME NEEDED FEATURES FOR A FUTURE VERSION...........................................................................49

8.2.1. How to deal with UN/Cefact data types?..............................................................................49 8.2.2. How to deal with the sequence order of simple properties and complex properties at UML and XSD side? ....................................................................................................................................49 8.2.3. How to deal with “Property Grouping” ..................................................................................49

9. . APPENDIX A: WHY ASSOCIATION CLASSES ARE SO IMPORTANT? ..............................50 9.1. ASSOCIATION CLASS......................................................................................................................50 9.2. USE CASE EXAMPLE ......................................................................................................................50

9.2.1. First Business case ..............................................................................................................51 9.2.2. Second business case .........................................................................................................51 9.2.3. Using association class to enhance modeling .....................................................................51

9.3. CONCLUSIONS ...............................................................................................................................52 9.3.1. Improving Accuracy and Consistency of the UML business modeling thanks to the use of association classes. ............................................................................................................................52 9.3.2. Better Compliancy with UN/Cefact CCTS methodology derivation process thanks to the use of association classes ..................................................................................................................52

EDF R&D


H-R49-2006-04284-EN


1. Reference documents • [1] XML NDR (Naming and Design Rules) V2.0 Author: UN/Cefact Date: 17 February 2006

• [2] 61968 NDR v01 draft Author: Xiaofeng Wang for IEC (International Electrotechnical Commission) TC57 Date: draft July 2006

• [3] CCTS (Core Components Technical Specification) V2.1 Author: UN/Cefact Date: 15 November 2003

• [4] IEC 61970 and 61968 standards Author : IEC TC 57

2. Overview

The goal of this document is to provide recommendations to facilitate XML data exchange between electrotechnical applications, although they could also be used for other applications.

Nowadays, IT designers found that having a shared semantic could facilitate interoperability between applications. That is why some working groups such as IEC (International Electrotechnical Commission) are building Information Model (like the IEC Common Information Model CIM), that describes data and its associated semantic that can be exchanged in a specific business domain. UML (Universal Modeling Language) is the language used to model data and express this semantic, and XML (eXtensible Markup Language) is the preferred syntax to exchange data by means of message content.

So, rules and methods, defining how to map UML to XML Message Content and how to preserve semantic in the mapping, must be defined.

At the moment, UN/Cefact (United Nations/Centre for Trade Facilitation and Electronic Business) is making an important work on this subject. The various concepts developed by UN/Cefact are exactly what we need to endorse some needs such as:

• Reusability: being able to reuse a work already made from a business process into another one. For example, we may want to reuse for a new message a business component already defined for another message.

• Traceability: being able to understand and validate automatically the definition of customized data coming from the reuse of a shared semantic. When we want to build a message by using an existing semantic, we need to know how the data of the message are defined and what concepts from the shared semantic have been used to build those message data.

• Interoperability: automate and facilitate XML data exchange if those data definitions are following those methodologies and rules.

However, UN/Cefact work is still in progress, and because Message Assembly is missing and XML NDR lacks some features to deal with these Message Assembly aspects, this missing parts needs to be filled. That is why EDF R&D needed to make an adaptation of these works in order to take advantage of it. This document is presenting the EDF R&D adaptation of UN/Cefact work as well as some proposals to deal with UN/Cefact specifications missing parts..

Note: in this document, we are using the CIM as our Information Model. CIM is not yet fully compliant with UN/Cefact CCTS, especially at the datatypes level. So in the following example, UN/Cefact datatypes are not treated.

3. What was the trigger of this study?

3.1. CIM: The IEC TC 57 Common Information Model IEC TC 57 Working Groups have defined a UML Information Model called the CIM (Common

EDF R&D


H-R49-2006-04284-EN


Information Model). This UML model describes all the artefacts needed for Generation, Transport, Distribution and Market operations of Power Utilities. It has more than 500 classes, 1200 attributes and 400 associations. Its main characteristics are:

• Asset/hardware modelling separated from the functional/treatment modelling view at UML design. So each asset has its own link on a functional object.

• UML packages hierarchy following the set of electrotechnical sub-domains.

• All attributes and associations are optional: indeed the CIM model is a generic UML model

• Use of inheritance for a lot of classes: because of the numerous concepts defined into the CIM, it was easier to share some attributes between classes by defining those shared attributes in some super classes.

• Use of bidirectional associations between classes: this use simplify CIM modelling and reading,.

• Use of Association Classes: association gives information on an association.

• Use of specific datatypes: the CIM model is dedicated to electricity domain. So it needed to contain some predefined dataTypes dedicated to electricity.

So it looks like this in the UML tool:

Organisation

organisationCode : StringcurrentStatus : StringstatusDate : AbsoluteDateorganisationType : StringcostCenterFlag : booleanprofitCenterFlag : booleanmode : StringmarketRole : StringoptOut : boolean = "false"governmentID : String

(from TopLevel)ErpPerson

lastName : StringfirstName : StringmName : StringspecialNeeds : StringgovernmentID : String

(from ERP_Support)

+Organisations +ErpPersons0..n

0..n0..n

0..n

OrgErpPersonRole

clientID : String(from TopLevel)

Figure 1 : basic view on a CIM class diagram

Note that here associations are bidirectional and are not named, but they have roles at both ends (+Organisations and +ErpPersons), and note that association could have association class (OrgErPersonRole).

But the CIM UML class diagrams are in genral more complicated because of the use of inheritance:

EDF R&D


H-R49-2006-04284-EN


Organisation

name : StringaliasName : Stringdescription : StringpathName : StringorganisationCode : StringcurrentStatus : StringstatusDate : AbsoluteDateorganisationType : StringcostCenterFlag : booleanprofitCenterFlag : booleanmode : StringmarketRole : StringoptOut : boolean = "false"governmentID : String

(from TopLevel)

ErpPerson


(from ERP_Support)

+Organisations +ErpPersons

0..n0..n 0..n0..n

OrgErpPersonRole

roleType : Stringprivilege : Stringstatus : StringstatusDate : AbsoluteDateclientID : String

(from TopLevel)

Role

privilege : StringroleType : Stringstatus : StringstatusDate : AbsoluteDate

(from Naming)

Naming

aliasName : Stringdescription : Stringname : StringpathName : String

(from Core)

Figure 2 : Use of inheritance in CIM UML Model

As you can see, Classes inherit from Naming and Role. For those diagrams, we used the UML tool Rational Rose that has some limitations in the graphical drawing of classes. So in reality, we should have had the following class diagram:

Organisation

name : StringaliasName : Stringdescription : StringpathName : StringorganisationCode : StringcurrentStatus : StringstatusDate : AbsoluteDateorganisationType : StringcostCenterFlag : booleanprofitCenterFlag : booleanmode : StringmarketRole : StringoptOut : boolean = "false"governmentID : String

(from TopLevel)

ErpPerson


(from ERP_Support)


0..n0..n 0..n0..n

OrgErpPersonRole

roleType : Stringprivilege : Stringstatus : StringstatusDate : AbsoluteDateclientID : String

(from TopLevel)

Figure 3 : Real graphical CIM classes definition

That is this kind of classes we are dealing with in the CIM UML Model for example when we build XML message Schemas using the CIM semantic.

EDF R&D


H-R49-2006-04284-EN


3.2. IEC TC 57 Message Exchange IEC TC 57 WG14 is defining generic messages between electrotechnical applications. This means that, apart from selection of Classes with relevant associations for a particular message, there are no other restrictions: all attributes are optional, all relations too, and datatypes are not further restricted. And following this selection, an XML Schema representing this particular message is generated: this is called a “Generic XSD”.

But in a some particular contexts (for example an application), this generic message must be constrained: some attributes could be mandatory, Datatypes could be restricted … The result is a new XML Schema (called “Restricted XSD”) that convey all the business restrictions. So, the question was: could we have instances that could be validated against the two schemas? Or could some applications, that are not aware of the restrictions, process the restricted XML instances?

This is what we call “Instance Interoperability”, and we will explain it more in detail in part 4.5.2, 5 and 6.

EDF R&D


H-R49-2006-04284-EN


4. UN/Cefact Core Component methodology

4.1. CCTS UN/Cefact CCTS (Core Component Technical Specification) methodology describes four different modeling levels that enable XML (eXtensible Markup Language) schemas building for message content which are based on a shared semantic contained into a UML information model. This shared semantic increases interoperability between applications exchanging information.

Figure 4 : UN/Cefact Core Component Methodology

This CCTS specification is considering four modeling levels:

• UML Information Model: this UML model describes all the core concepts (Core Components) that could be found in a generic domain. This is the model that will be shared by different Business Domains or different contexts.

• UML Contextual Model: in a second step, usually a business process, main core concepts of the information model are redefined (BIE Business Information Entities) by adding restrictions on their properties and by defining a hierarchy, in order to express business process specific needs So new concepts cannot be added at this step because we can only restrict the information model. If we need core concepts that are not in the information model, the information model should be extended first (This document is showing an extension example see §5.2.1.2). Note also that each BIE is just defined for one context use.

• UML Message Content Model: the next step is to define what message architecture and content will be, or in another way how Business Information Entities are assembled to create the Message. There are different ways to make this assembly: one is based on Business Entities sequencing and containment and the other on Business Information Entity properties grouping in container. But this is not yet defined (work is in progress at UN/Cefact level)

• Implementation Message Model: for each UML message content model, an implementation message model could be produced in a specific syntax using an appropriate programming

UML Information Model

UML Contextual Model for a Business process

XSD Implementation Message Model

UML Message Content Model

EDF R&D


H-R49-2006-04284-EN


language. In our case, the syntax is XML, and we want to specify XML Schemas (XSD)

CCTS describes these four levels but only gives details for the first two levels (Information Model and Contextual Model): how to define Core Components and how to derive Business Information Entities from them.

An other UN/Cefact document “XML NDR” describes relations between UML constructs (Core Components or Business Information Entities) and XML constructs, and describes what are the allowed XML Schema constructs.

To fully implement this derivation process there are two other specifications that are being developed : one for “Message Assembly” and one for “Context”. These documents should give rules to define Message Content Assembly and to apply Business Rules according to Context.

Because “Message Assembly” and “Unified Context Methodology” have not been yet released, there are no ways to redefine or restrict Business Information Entities at Message level. So XSD generation could be done only with some added rules. This document will make some proposals to overcome these lacks.

4.2. CCTS Methodology proposed evolution

4.2.1. Introduction When looking at real Business cases like the one we will present in the document, there are in fact additional levels that should be taken into account and we propose:

• to add one level in the modeling view, introducing sub context level and by consequence also Business Information Entities derived from other BIEs,

• to express needs for Message Assembly Rules and Contextual Business Rules,

• to give some additional rules for XML Schema Design.

EDF R&D


H-R49-2006-04284-EN


4.2.2. Basic CCTS proposed evolution

UML Information Model For a Generic Domain

UML Contextual Model for a Business Domain

XSD Implementation Message Models

UML Message Sub-Contextual Models

UML Message Assembly Models

CCTS

BCSS

UCM

Message Assembly

XLM NDR

Figure 5 : proposed Methods

The proposed methodology considered now five model levels:

• UML Information Model (Core Components model): this UML model is the definition of all the core concepts of a generic domain (CIM for example).

• UML Business Contextual Model (Business Information Entities BIE): at this level, we restrict the Information Model to the Core Components that are relevant for a Business domain (ex: Customer switching) and restricts their properties and datatypes.

• UML Message Sub-Contextual Models: at this level, they are usually several sub contexts (for example the different message exchanges in a Business process) and therefore different Models. Each sub context (message exchange) reuses some BIEs of the parent contextual level but adds some restrictions: this means defining new BIEs based now on other BIEs. For each message exchange, the sub contextual model contains all the BIEs that will make Message Content.

• UML Message Assembly Models (Business Containers): at this level, BIEs of the sub contextual model are assembled to create a Message Content conforming to some Message Architecture and assembly rules.

• XSD Implementation Message Models: for each UML message model, we can generate an XSD according to some rules (XML NDR plus some additions).

EDF R&D


H-R49-2006-04284-EN


4.2.3. Full CCTS proposed evolution

1

0..N

Sub-Context/ Business Sub-Domain

Syntax Binding Profile 1

Syntax Binding Profile 2

Syntax Binding Profile N

Msg Assembly Profile 2

Msg Assembly Profile N

Msg Assembly Profile 1

UML Information Model For a Generic Domain

UML Contextual Model for a Business Domain


UML Message Sub-Contextual Models

UML Message Assembly

Model

CCTS

BCSS

UCM

Message Assembly

XLM NDR


Model


Model



Figure 6 : Full CCTS proposed evolution The full proposed evolution is adding two new concepts:

• Recursivity in the UML Contextual Model for a Business Domain: In a real business use case, a hierarchy of Contexts needs to be defined. Each Sub-Context represents a Sub-Business Domain. In each Sub-Context, new restrictions set on the parent context can be defined to better handle those Sub-Business Domain needs. For example, in a business context related to the distribution domain, we can define inside this domain several sub-domain for each business processes belonging to the parent distribution domain. Then for each business process, some other sub-contexts can be defined to handle each application participating in this business process.

• Profile for Message Assembly/syntax binding: This is important to see that a UML Message Sub-Context Model can be derived in several XSD Implementation Message Models by applying different Profiles containing the assembly and XSD syntax binding generation rules.

4.3. UN/Cefact main specifications There are five different projects that are underway at the Core Component Working Group (CCWG) and Applied Technologies Working Group (ATG):

• CCTS : Core Component Technical Specification

• Message Assembly

EDF R&D


H-R49-2006-04284-EN


• BCSS : Business Collaboration Specification Schema

• XML NDR : Naming and Design Rules

• UCM : Unified Context Methodology

UN/Cefact Documents

CCTS Message Assembly

BCSS XML NDR

UN/Cefact Working Group

CCWG CCWG CCWG ATG

Modeling Level 1

Information Model

Core Components

Core DataTypes

Contextual Model

Business Information Entities

Business dataTypes

Modeling Level 2

Sub Contextual Model

UML profile support for CCTS

XML Schema generation rules

Modeling Level 3

Message Content Model

Assembly Rules

UML profile for message assembly

Modeling Level 4

message content XML

Implementation model

XML Schema Assembly Rules

Output Files XMI XSD

Figure 7 : overview about UN/Cefact Core Component works At the date of this document, UN/Cefact is not covering all the recommendations on:

• How to assemble components in Message Content,

• How to generate XSD files from Message Assembly level, but only from contextual level,

• Further more, the UML profile (BCSS Business Collaboration Specification Schema) is based on UML 1.x version and does not take advantages of new UML 2.0 profile extending UML capabilities.

So for the time being, we only have the CCTS and XML NDR specifications. (Note a CCTS version 2 is on track, and is due for January 2007).

That is why, EDF R&D worked on an adaptation of the UN/Cefact specifications in order to endorse some important needs in UML step and message assembly step. This document is presenting EDF adaptation of those concepts and a proposition for XML message content design that could serve as an input for WG 14 XML NDR document (§1 Doc [2]).

4.4. Message Assembly Needs There are two different needs at this level: design a Message Architecture and define BIEs assembly

EDF R&D


H-R49-2006-04284-EN


rules.

4.4.1. Message Assembly Architecture At this level, besides BIE, some specific components are added usually at the top level to define the Message Content: a message header for example. In the CIM, a message content is composed by:

• A Message Type Component

• A Control Area Group Component

• A Message Payload Component

• And the Message Content, starting with the first ABIE (Aggregate Business Information Entities) defined in the Message Sub Contextual Model

Note there are a lot of discussions about message architecture, the three components (Message Type, AreaGroup and Message Payload) are special: are they or not Core Component and BIE? We think it should be. The only difference is that Message Payload could be associated with any ABIE. As it is at the Message Assembly level that the association is achieved, it should only be expressed by a special relation: here our proposal is to stereotype a named aggregation with <<MessageLink>>. The name of this relation will be the name of the root ABIE.

ControlAreaGroupverbnounrevisiontimeStamp

<<ABIE>>

MessageTypeid

<<ABIE>>

1

1

1

1controlAreaGroup

<<ASBIE>>

MessagePayload<<ABIE>>

11

Payload

<<ASBIE>>

RootABIE

RootABIEName

<<MessageLink>>

Figure 8 : Message Assembly Architecture

4.4.2. ABIE Assembly There are different methods to do ABIEs assembly:

1. ABIE straight containment :

o With or without “sequencing”

o With or without explicit “traceability”

o With or without “instance interoperability”

2. ABIE “properties grouping” in containers.

The assembly starts always with the UML Message Sub-Contextual Model where ABIEs are already placed in a hierarchy with one root ABIE (A tree-Architecture of ABIEs).

EDF R&D


H-R49-2006-04284-EN


We could as well define other way to define the assembly. That is way assembly profiles have to be defined in order to achieve at XSD final implementation model some specific goals (see §4.2.3).

4.4.2.1. Sequencing Assembly

In the UML Message Sub-Contextual Model, each ABIE is part or contained in another ABIE (in the UML model every ABIE aggregates or is aggregated in another ABIE). At Message Assembly Model level, it should be defined in which sequence order this hierarchy is assembled. This means that a rule must say how the tree-structure is ordered. One way of doing it, is to give a sequence number for each aggregation. And, in the Message Assembly, ABIEs will be placed according to this order. (In the next version of CCTS V3.0, a sequence number could be associated to each associated property).

Cus_ErpCivility<<ABIE>>

CuS_ErpTelephoneNumber<<ABIE>>

CuS_ErpAddress<<ABIE>>

CuS_ErpPerson<<ABIE>>

Cus_ErpCivility

CuS_ErpTelephoneNumber

CuS_Per_ErpAddress

Figure 9 : UML Message Sub-Contextual Model





Cus_ErpCivility


CuS_Per_ErpAddress

1

2

3

Figure 10 : UML Message Assembly Model

4.4.2.2. Traceability

“Traceability” is the fact that the Message should bared explicitly the relation between an ABIE and its parent ACC (Aggregate Core Component) (or ABIE): it means that the “isBasedOn” relationships should be kept.

EDF R&D


H-R49-2006-04284-EN



CuS_Organisation<<ABIE>>

1

0..1

1

0..1

CuS_ErpPerson

<<ASBIE>>

Organisation<<ACC>>

ErpPerson

<<isBasedOn>>

<<isBasedOn>>

<<ASCC>>

ErpPerson------------------------->

<<isBasedOn>>

Figure 11 : traceability

Each association ASCC (Association Core Component) between ACCs can also be restricted in order to define an association ASBIE (Association Business Information Entities) between ABIEs.

4.4.2.3. Instance Interoperability

This has to deal with the ability to process a component instance, even if the application is not aware of the restrictions that have been applied to the corresponding ‘Aggregate Core Component”. In order to do that at Message Assembly level, we are going to substitute the ASBIE name by the ASCC name.





Cus_ErpCivility


CuS_Per_ErpAddress<<ASBIE>>

<<ASBIE>>

<<ASBIE>>

Figure 12 : Message sub-Contextual Model





ErpCivility

ErpTelephoneNumber

ErpAddress

<<ASCCSubstitution>>



Figure 13 : Message Assembly Model with instance interoperability

Note: one option is to introduce a new stereotype for these Associations (ex: <<ASCCSubstitution>>).

This rule for this choice of association role name is important in order to have at XSD Implementation

EDF R&D


H-R49-2006-04284-EN


Model a tree-architecture of XML objects named with the Information Model Classes Name. Therefore, following this message assembly profile rule, the Information Model naming conventions and structures are reflected and projected inside the final XSD implementation message model (see §4.5.2, §6.2.5.2 and §7.3).

4.4.2.4. Properties grouping

One other method for assembly is to define classes where properties of aggregated BIEs could be grouped. Usually this is done for ABIEs that have a one to one relationship. Grouping Properties in a component means that we have a new kind of component different from Aggregate Core Component and ABIE: we call it “container”.

CuS_Civilitycivility

<<ABIE>> CuS_ErpTelephoneNumbercountryCodelocalNumber

<<ABIE>>

CuS_ErpPersonname

<<ABIE>>

0..10..1

CuS_ErpAddressstreetNumberstreetName

<<ABIE>>

0..10..1

0..1 0..1


CuS_ ErpPersonnamecuS_Civility.civilitycuS_ErpTelephoneNumber.CountryCodecuS_ErpTelephoneNumber.localNumbercuS_ErpAddress.StreetNumbercuS_ErpAddress.StreetName

<<container>>

Figure 15 : UML Message Assembly Model for property grouping

4.4.2.5. Assembly Rules Profiles

Basically, we listed four kinds of Message Assembly profiles:

• Simple Message Assembly

• Traceable Message Assembly

• Property Grouping Message Assembly

• Traceable, reusable and instance interoperability Message Assembly.

Sequencing could be used in any of the four. In the next part of the document we will focus just on Message Assembly where traceability, reusability and instance interoperability are the target.

Note: Message Assembly rules are (without explicit traceability) or are not (grouping) yet covered by UN/Cefact documents.

EDF R&D


H-R49-2006-04284-EN


4.5. XSD design needs

4.5.1. Introduction At the implementation Model level or XSD generation, there are several options that should reflect the different rules of Message Assembly. “XML Naming and Design Rules” says how ABIEs, their properties and their datatypes should be expressed as XML element or complex or simple types. Does it give all the rules to achieve:

• “Traceability”: do we want that the XSD keeps track of how ABIE were derived from (or based on)?

• “Reusability”: do we want to be able to share ABIEs through XSD?

• “Instance Interoperability”: do we want to be able to process instances by generic schema and restricted schemas? Do we want final XSD model to reflect naming conventions of the Information model in order to facilitate XML interoperable exchanges?

At UML level, we have seen that we could describe all this. How to reflect this at XSD level?

Here what we try to solve is to have all these properties in our XSD. That is why here we are not looking for Message Assembly at “properties grouping” because it misses at least traceability and reusability.

So in order to have:

• Traceability; we must express the “is based on” relationship between Core Components and Business Information Entities. XSD offers some mechanisms like “<xs:restriction base=”Parent Component”>”. This mechanism enables to keep track on the Parent Component and also define the restrictions on this Parent Component.

• Reusability: each ABIE must be expressed as a “named Type”. This well done in XML NDR.

• Instance Interoperability: this has to deal with the ability to process a component instance, even if the application is not aware of the restrictions that have been applied to the corresponding ‘Aggregate Core Component”. This is the case when generic kinds of XSD are generated (like WG 14 Message Type), and then these Messages are restricted in some applications.

Note: Instance Interoperability in this sense cannot be achieved if “grouping properties” mechanism is used.

To achieve these goals we are going to see that we need to generate not only XSD at Message Assembly level but also at all the UML levels (see §6.2.1).

EDF R&D


H-R49-2006-04284-EN


4.5.2. Some details about instance interoperability at XSD level Let us take the example with two classes:

ErpPersonlastName [0..1] : StringfirstName [0..1] : String

<<ACC>>Organisationname [0..1] : StringorganisationCode [0..1] : StringmarketRole [0..1] : StringorganisationType [0..1] : String

<<ACC>>

0..n

+ErpPerson

0..n

UML Information Model Level

MarketRole_enumBalanceSupplierMeteringPointAdministratorConsumer

<<Enumeration>>

CuS_ErpPersonlastName [1] : StringfirstName [1] : String

<<ABIE>>

CuS_Organisationname [1] : StringorganisationCode [1] : StringmarketRole [1] : MarketRole_enum

<<ABIE>>

0..1+CuS_ErpPerson

0..1

UML Message Assembly Model

Generic XML instance

Based on this information model

Restricted XML instance

Based on a restrictions set on the information model

Will lead to an instance of this kind Will lead to an instance of this kind

<Organisation> <name>EDF</name> <organisationCode>abcdefgh</organisationCode> <marketRole>gkfioererfdsflfk</marketRole> <organisationType>gkfioererfdsflfk</ organisationType > <ErpPerson> <lastName> Dupont</lastName> <firstName>Pierre</firstName> </ErpPerson> </Organisation>

<CuS_Organisation> <name>EDF</name> <organisationCode>45621</organisationCode> <marketRole>BalanceSupplier</marketRole> <CuS_ErpPerson> <lastName> Dupont</lastName> <firstName>Pierre</firstName> </CuS_ErpPerson> </CuS_Organisation>

Here all attributes are mandatory. marketRole must respect the list of enumerated values.

Not the same as

But here, the resulting instance of the restricted schema could not be processed by a generic schema because names are not the same (ex: CuS_ErpPerson in the above restricted XML instance). What we would like to have is:

EDF R&D


H-R49-2006-04284-EN



<<Enumeration>>


<<ABIE>>


<<ABIE>>

0..1+CuS_ErpPerson

0..1

UML Messsage Assembly Level without Instance interoperability

<CuS_Organisation> <name>EDF</name>

<Organisation>

<organisationCode>45621</organisationCode> <marketRole>BalanceSupplier</marketRole>

<CuS_ErpPerson> <lastName> Dupont</lastName> <firstName>Pierre</firstName>

</CuS_ErpPerson> </CuS_Organisation>

Obtained XML restricted instance !!!! We do not want this kind of XML instance because the XML elements CuS_Organisation and CuS_ErpPerson are not following the naming convention of the information model. So it should be named Organisation and ErpPerson.

<name>EDF</name> <organisationCode>45621</organisationCode> <marketRole>BalanceSupplier</marketRole>

<ErpPerson> <lastName> Dupont</lastName> <firstName>Pierre</firstName>

</ErpPerson> </Organisation>

Wanted XML restricted instance !!!!

As you can see on this example, we want Restricted and Generic XML Instances to keep the same naming conventions and structure as the information model. We also want to have Restricted XML instances being able to be validated against the same XSD validating the Generic XML instances.

So the question is: can we generate a “restricted XSD” that gives the same XML instances than the “generic XSD”, and still have all the restrictions that are defined, and keep track of the elements on which the restrictions are applied?

In order to reach this goal we are going to use what we call “<<ASCC Substitution>>, which enables us to have XML elements named with the same names that the information model class ones. This allows XML instances to have the same naming conventions.

BUT WE WANT

EDF R&D


H-R49-2006-04284-EN


ErpPersonlastName [0..1] : StringfirstName [0..1] : String

<<ACC>>Organisationname [0..1] : StringorganisationCode [0..1] : StringmarketRole [0..1] : StringorganisationType [0..1] : String

<<ACC>>

0..n

+ErpPerson

0..n

UML Information Model Level


<<Enumeration>>


<<ABIE>>


<<ABIE>>0..1 +ErpPerson0..1


UML Message Assembly Model

with instance interoperability

using ASCC Substitution

Valid against a Generic XSD Valid against a Restricted XSD as Well as a Generic XSD

Generic XML instance

Based on this information model

Restricted XML instance

Based on a restrictions set on the information model

VALID !!! <Organisation> <name>EDF</name> <organisationCode>abcdefgh</organisationCode> <marketRole>gkfioererfdsflfk</marketRole> <organisationType>gkfioererfdsflfk</ organisationType > <ErpPerson> <lastName> Dupont</lastName> <firstName>Pierre</firstName>

VALID !!! <Organisation> <name>EDF</name> <organisationCode>45621</organisationCode> <marketRole>BalanceSupplier</marketRole> <ErpPerson> <lastName> Dupont</lastName> <firstName>Pierre</firstName> </ErpPerson>

</ErpPerson> </Organisation> </Organisation>

Here all attributes are mandatory. marketRole must respect the list of enumerated values.

For example, marketRole could not have taken the value SystemOperator.

:

EDF R&D


H-R49-2006-04284-EN


5. Example based on an adaptation of UN/Cefact methodology

5.1. Description of the business example We are going to use a simple business example in order to explain easily the XSD generation proposition of this document (see §6).

Let us take the following example: We want to build a XML message containing data from the CIM (IEC UML Model for the whole electricity domain standing for Common Information Model) that represents our shared semantic for our business study. So the CIM model is going to play the role of the information model in the UN/Cefact CCTS Methodology.

In this XML message, we want to give information about a company as well as a contact for this company.

5.2. UML modeling for this business example We are now going to make a UML study for this simple business example.

5.2.1. UML Information Model (Core Components Model)

5.2.1.1. CIM generic Model

OrgErpPersonRole<<ACC>>

Organisation<<ACC>>

Location<<ACC>>0..n

0..n+Organisations

0..n

+Locations0..n

ErpAddress<<ACC>>

ErpPerson<<ACC>>

0..n

0..n

+ErpPersons 0..n

+Organisations 0..n

0..n

0..n

+ErpAddresses

0..n

+ErpPersons0..n

ErpTelephoneNumber<<ACC>> 0..n

0..n+ErpPersons

0..n

+ErpTelephones

0..n

Figure 16 : CIM model playing the role of the UN/Cefact Information Model

Those classes represent the UN/Cefact ACCs (Aggregate Core Components) that we found while browsing the CIM model. Those classes have been selected because they endorse our needs for our message:

• Organisation: This class represents a generic Organisation.

EDF R&D


H-R49-2006-04284-EN


• ErpPerson: each Organisation may contain several contacts represented by the ErpPerson class.

• OrgErpPersonRole: this association class is representing a role adding information upon the link between an Organisation and its contact.

• ErpTelephoneNumber: this class is containing information about the telephone number of the contact.

• ErpAddress: this class is containing information about the address of the contact.

• Location : this superclass contains the attributes used in ErpAdress.

5.2.1.2. Extensions of the UML information model

When selecting an ACC from the information model, we may lack some important concepts that were not taken into account in the information model. So we need to be able to extend the information model with specific concepts.

In our example, we are making the hypothesis that the information model is not having the concept of civility (Mr, Miss or Mrs) for a contact. So we need to extend the information model by creating a generic core concept about this civility. This new core concept needs to be generic because it could be used in several messages like the one we are working on. So each message would add its own business restrictions.

ErpCivilitycivility : String

<<Extension>>

ErpPersonlastName : StringfirstName : StringmName : StringspecialNeeds : StringgovernmentID : String

<<ACC>>

0..1

1

+civility0..1

+person1

<<Extended By>>

Figure 17 : extensions of the UML Information model

In order to extend ErpPerson class, we created a new class ErpCivility containing all properties used to extend ErpPerson class. In our example, we only have one property to add (civility: String).

PS: this <<Extended by>> association is not a basic UML association but a new one that needs to be defined at the UML meta-model level in a new UML profile. This is important to define those specific information model extensions into a new UML package that is not inside the UML information model in order not to modify it. Indeed, the information model that we are using may be a norm (ex: the CIM model) that we are not allowed to modify. Defining all model extensions in a specific external package also enables to associate them with a new namespace (it is useful at XSD generation level). So at XSD generation step, we will be able to recognize and distinguish easily what is coming from the shared information model from what is coming from our own model extensions (see §6.2.3).

5.2.1.3. Associations

In CIM, as there are a lot of associations between classes, these associations are represented by bidirectional ones, when one ACC could be the property of another one. All those bidirectional

EDF R&D


H-R49-2006-04284-EN


associations are in fact representing two aggregations, as it is expressed in CCTS. In the CIM, because of this bidirection, associations are not named, instead they have two roles. These two roles could be seen as the names of the two aggregations.

Organisation

ErpPerson

0..n

0..n

+ErpPersons

+Organisations

0..n

0..n

ErpPerson<<ACC>>

Organisation<<ACC>>

0..n

0..n

ErpPersons

0..n

0..n

Organisations============>

<<ASCC>>

<<ASCC>>

Figure 18 : CIM Associations decomposition

5.2.1.4. Association Class

Association Classes are not part of CCTS, but as it exists in the CIM, we have to find a way to deal with it. Association Class defines in fact a complex property of an ASCC. So the proposal is to add this kind of property, that could be <<ASCC.ASCC>>, that should have a name. It will look that this:

Organisation<<ACC>>

ErpPerson<<ACC>>

ErpPerson

<<ASCC>>OrgErpPersonRole

<<ACC>><<ASCC.ASCC>>

OrgErpPersonRole

Figure 19 : Association Class

5.2.2. UML Contextual Model (Business Information Entities) for our business domain

5.2.2.1. Selection of required information model UML objects

The generic information model (CIM model in our example) may contain core concepts for many uses that are not necessarily relevant for our specific business study (Location class for example). Here, we only want to select specific core concepts from this model.

EDF R&D


H-R49-2006-04284-EN



ErpTelephoneNumber<<ACC>>

ErpAddress<<ACC>>

Organisation<<ACC>>

Location<<ACC>>

+ErpTelephoneNumbers0..n +ErpAddresses

0..n

+ErpPersons0..n0..n

0..n

+ErpPersons0..n0..n

0..n

0..n

0..n

+ErpPersons0..n

+Organisations0..n +Organisations

0..n

+Locations

0..n

0..n

0..n

ErpPerson<<ACC>>

Figure 20 : selected information model objects

EDF R&D


H-R49-2006-04284-EN


5.2.2.2. Restrictions of Information Model selected Objects

Once we selected all needed information model core concepts, we need to define our UML contextual model by adding restrictions upon the core concepts from this information model. Those restrictions can be set on:

• ACC in order to define ABIE (Aggregate Business Information Entity), that represent restricted views of ACC. We can restrict the number of used properties and their data types. An ACC contained properties called BCC (Basic Core Component). A restricted BCC becomes a property called BBIE (Basic Business Information Entity).

• ASCC (Association Core Component) in order to define ASBIE (Association Business Information Entity), that represents restricted aggregations between ABIE. We can restrict aggregations by restricting cardinalities, navigation direction, or ownership with composition (See Figure 22).

CuS_ErpCivility<<ABIE>>



CuS_OrgErpPersonRole<<ABIE>>



0..1 0..1

11

0..1

11

0..1

1

0..1

1

0..1

0..n

1

0..1

1

0..1

11

0..n

Organisation<<ACC>>


ErpPerson<<ACC>>

ErpTelephoneNumber<<ACC>>

ErpCivility<<Extension>>

ErpAddress<<ACC>>

<<Is based On>>

<<Is based On>>

<<Is based On>>

<<Is based On>><<Is based On>>

<<Is based On>>

Figure 21 : contextual model based on the information model by adding restrictions

Each ABIE is therefore based on an ACC. We can see in this example that the ABIE are prefixed with CuS_ (the qualifier in CCTS specification). CuS is related to our business context and stands for Customer Switching. Indeed, this example is extracted from a real EDF business process called Customer Switching.

EDF R&D


H-R49-2006-04284-EN


Is based on



1

0..1

1

0..1

Organisation <<ACC>>

ErpPerson<<ACC>>

0..n

0..n 0..n

0..n

Restrictions on

Restrictions on

<<ASBIE>> Cus_ErpPerson

<<ASCC>> ErpPerson

<<ASCC>> Organisation

Figure 22 : detailed view on the restrictions set on the associations between

Organisation and ErpPerson As you can see here we are decoupling the bidirectional association in two named aggregations. Here we took the CIM association role for the association names. You should remember that the name of the association is in fact the name of the complex property:“CuS_Organisation” has a “CuS_ErpPerson” property which is of type “CuS_ErpPerson”.

CuS_OrgErpPersonRoleroleType : OrgPersonRole_enum

<<ABIE>>

CuS_Organisationname StringorganisationCode : StringmarketRole : MarketRole_enum

<<ABIE>>

CuS_ErpAddressstreetNumber : StringstreetName : Stringcity : Stringcountry : StringpostalCode : Integer [5]

<<ABIE>>

0..n

1

0..n

1

CuS_Org_ErpAddress

CuS_ErpTelephoneNumbercountryCode : Int [2]localNumber : Int [10]

<<ABIE>>Cus_ErpCivility

civility : Civility_enum

<<ABIE>>

CuS_ErpPersonlastName : StringfirstName : String

<<ABIE>>

0..1

1

0..1

1

CuS_ErpPerson

0..1

1

0..1

1CuS_Per_ErpAddress

0..1

1

0..1

1


0..1

1

0..1

1Cus_ErpCivility

Cus_OrgErpPersonRolecontact

<<enumeration>>

Civility_enumMrMrsMiss

<<enumeration>>

MarketRole_enumbalanceSuppliermeteringPointAdministratorconsumer

<<enumeration>>

Figure 23 : final view on the contextual model

The Figure 23 is a detailed view on the contextual model. We can see all selected properties of each class coming from the information model. For example, the ABIE CuS_ErpPerson only has two properties (lastName and firstName) selected from the ACC ErpPerson because the other properties were not relevant for our specific business context.

EDF R&D


H-R49-2006-04284-EN



<<ABIE>>


<<ACC>>

<<Is based On>>

Figure 24 : detailed view on the restrictions set on ErpPerson

Each property data type may have been also restricted. For example, the marketRole property of Organisation has the generic type String in the information model whereas in the contextual model, this String type is restricted with the use of the enumeration MarketRole_enum. All those restricted data types are called BDT (Business Data Type). A BDT is therefore based on a generic type called DT (Data Type) from the information model.

marketRole: String<<BCC>>

CuS_Organisationname : StringorganisationCode : StringmarketRole : MarketRole_enum

<<ABIE>>

Organisation name : StringorganisationCode : StringcurrentStatus : StringstatusDate : AbsoluteDateorganisationType : String costCenterFlag : booleanprofitCenterFlag : booleanmode : StringmarketRole : StringoptOut : boolean = "false"governmentID : String

<<ACC>>

<<Is based On>>

0..1

11

0..1

String <<DT>>

MarketRole_enumBalanceSupplier MeteringPointAdministrator Consumer

<<BDT Enumeration>>

<<Is based On>>

<<Is based On>>

<<Is Of Type >>

Figure 25 : detailed biew on the ABIE CuS_Organisation definition At the moment, in the EDF R&D adaptation of the UN/Cefact Core Component methodology, we propose that the list of possible data type restrictions (for properties) is the same as the XSD facets in order to have direct linking with XSD and ease the XSD generation step. In a near future, we should take into account the UN/Cefact CCTS data types. In this example, by default we use basic UML data types mapped with XSD data types.

5.2.2.3. Contextual Association Class

At the contextual level we also have contextual association classes that should be treated in the CCTS spirit with ASBIE property <<ASBIE.ASBIE>> based on the previous <<ASCC.ASCC>>.

EDF R&D


H-R49-2006-04284-EN



<<ABIE>>


<<ABIE>>


<<ABIE>>

1

1

1

1

ErpPerson

<<ASBIE>>

CuS_OrgErpPersonRole

<<ASBIEASBIE>>

Figure 26 : Contextual Association Class

EDF R&D


H-R49-2006-04284-EN


5.2.3. UML Message sub-Contextual Model Once we designed the contextual model for our business context, we can reuse it to design the UML Message Sub-Contextual Model. So, each message content is defined into a sub-context under this business context. So for each message content, we can add new restrictions upon contextual model ABIEs.

The main goal of the UML Message Sub-Contextual Model is to define :

• new ABIEs based on previous ones,

• new constraints on ASBIE,

• and eventually , sequencing could be defined at this level if we want to freeze the sequencing definition at this level in order to retrieve it at assembly level. But Normally the sequencing is supposed to be defined at message assembly level.

Note: ABIEs are linked together in a tree-architecture at UML Message Sub-Contextual Model.


<<ABIE>>


<<ABIE>>


<<ABIE>>




<<ABIE>>


<<ABIE>>

1

1

1

1

MC_CuS_ErpPerson

1

1

1

1

MC_CuS_Per_ErpAddress

1

1

1

1

MC_CuS_ErpTelephoneNumber

1

1

1

1MC_Cus_ErpCivility


<<enumeration>>


<<enumeration>>


<<enumeration>>


You can notice in Figure 27 that the association (in the contextual model Figure 23) between CuS_organisation and CuS_ErpAddress disappeared because it was not relevant for this message. At message level, this association has been restricted by changing the cardinality 0..N into 0 at ErpAddress role side.

Here you can see also that some restrictions were added on associations, so we had to give them new names, at this sub contextual level. In a strict CCTS usage we should have also to change the names of the ABIEs, because at least one of their properties was changed (here their complex properties have been restricted).

Once we are in this step, we can now generate the Message Assembly Model.

EDF R&D


H-R49-2006-04284-EN


5.2.4. UML Message Assembly Model

5.2.4.1. UML Message Assembly Model profile without instance interoperability

At this stage, depending on the Message Assembly rules or profile, we could have different Message Assembly Models. The main goal of the UML Message Assembly Model is to link the root ABIE to Message Payload. If we just do that, we will have a Basic Profile Message Assembly Model


<<ABIE>>


<<ABIE>>




<<ABIE>>


<<ABIE>>

1

1

1

1

MC_CuS_Per_ErpAddress

1

1

1

1MC_CuS_ErpTelephoneNumber

1

1

1

1MC_Cus_ErpCivility


<<enumeration>>


<<enumeration>>


<<enumeration>>



<<ABIE>>

1

1

1

1

MC_CuS_ErpPerson

CuS_Organisation

<<MessageLink>>

Figure 28 : UML Message Assembly Model Profile without instance interoperability

5.2.4.2. UML Message Assembly Model Profile with instance interoperability

This profile is based on the use of <<ASCC substitution>>, that in our case means to substitute the name of the ASBIE (or name of complex properties), with the name of the ASCC it is based on. And this will lead to XML instance operability, as we will see in the next part on XSD generation:

EDF R&D


H-R49-2006-04284-EN



<<ABIE>>


<<ABIE>>




<<ABIE>>


<<ABIE>>

1

1

1

1ErpAddress

1

1

1

1

ErpTelephoneNumber1

1

1

1

ErpCivility


<<enumeration>>


<<enumeration>>


<<enumeration>>


<<ASCCSubstitution>><<ASCCSubstitution>>

Message Payload<<ABIE>>


<<ABIE>>

1

1

1

1

ErpPerson


11

Organisation

<<MessageLink>>

Figure 29 : UML instance interoperability profile Message Assembly Model

You can notice in Figure 29 Association name substitution.

Once we are in this step, we can now generate the implementation message model (XSD). The following parts of this document will now describe our proposition for XML schemas generation in message assembly by reusing this simple business example.

EDF R&D


H-R49-2006-04284-EN


6. Implementation message: proposal for XML Schemas generation

We are going in this part to describe syntax binding for a specific message assembly profile related to our proposal (see §4.4.2.5) dealing with:

• Traceability

• Reusability

• Instance Interoperability

6.1. General XSD Rules For this part, we adopt mainly the general UN/Cefact NDR (Naming and Design Rules) recommendations.

Figure 30 : general UN/Cefact NDR rules for XSD generation

Some of the UN/Cefact rules are not taken yet into account in this document.

We are not going to go through all UN/Cefact XML NDR rules in this document in order to define the list of respected rules. Indeed, this list of rules is covered by IEC 61968 NDR document (see Doc [2] §1).

EDF R&D


H-R49-2006-04284-EN


However, some of the UN/Cefact XML NDR rules are directly conflicting with EDF proposal for this Message Assembly target:.

• In this case, UN/Cefact XML NDR R80 cannot be applied . Indeed, we need to allow the use of XSD Restrictions on xsd:complexType in order to manage traceability between ACC and ABIE at XSD level as proposed in this document. UN/Cefact NDR is proposing to manage traceability with the use of the xsd:annotation element. In this document, traceability is proposed to be managed directly using the xsd:restriction ability (see §6.2.4). The main advantage of our proposition is to be able to validate using standard XML parsers:

o how the contextual data are defined

o the restrictions set on the information model data used to build those contextual data.

• UN/Cefact NDR R56 cannot be applied too. The elementFormDefault attribute must be allowed to take the value “unqualified” because a qualified value has consequences on reusability of ACC into ABIE based on this ACC defined in a different namespace (So into a different XSD file) as proposed in this document (see §6.2.1).

Those two rules R56 and R80 are really linked in the way they conflict with this proposal. Note: here we are dealing with IEC Information Model (CIM), whose datatypes are not compliant with CCTS. IEC is considering to make the move, so it will be considered for future UML and XSD versions.

EDF R&D


H-R49-2006-04284-EN


6.2. Implementation Message Model (XSD) generation rules

6.2.1. Modularity Presentation The main idea of our proposal is to generate XSD files by following the different model levels as shown in Figure 6.

Figure 31 : proposal for XSD generation architecture and modularity

So each level of UML modeling will have an equivalent in a XSD generation step. The given XSD file names are just example:

• InformationModel.xsd: It should only contain the XSD definitions of all UML information model Core Components.

• ModelExtensions.xsd: It only contains the extensions of the information model. Therefore, using a UML extension package (defining all extensions assigned to the XSD extension namespace) is very important The use of this new XSD namespace for extensions enables to recognize them clearly when used inside a message.

• ContexualDataTypes.xsd: it represents the Business Data Types BDT definition (data types used to restrict the data types of the information model).

• ContextualComponents.xsd: It represents the definition of all BIEs. • RealMessage.xsd: it contains the definition of message components using the contextual

Components, as well as directly the information model components or the extensions if they were not restricted at contextual level.

Note: you can notice that the XSD generation for the contextual model level is recursive like we said in the full CTTS proposed evolution (see §4.2.3).

Now, we are going to look more in detail at those XSD generation steps through examples based on the business example seen in part §5.

Sub-Context

0..N

UML Information Model level

UML Contextual Model level

UML Message Assembly Model level

UML World XSD Implementation Model

ModelExtensions.xsd

ContextualDataTypes.xsd

RealMessage.xsd

InformationModel.xsd

ContextualComponents.xsd

XSD Import

EDF R&D


H-R49-2006-04284-EN


6.2.2. UML Information Model to XSD The InformationModel.xsd file will contain all information model components as shown in §6.2.1.

For example, the <ACC>ErpPerson component will be generated as a xsd:complexType under the namespace called xmlns:cim="cimBase_informationModel".


<<ACC>><xs:complexType name="ErpPerson" mixed="false"> <xs:annotation> <xs:documentation>General purpose information for name and other information to contact people.</xs:documentation> </xs:annotation> <xs:complexContent mixed="false"> <xs:extension base="cim:Naming"> <xs:sequence> <xs:element name="lastName" type="xs:string" minOccurs="0"> <xs:annotation> <xs:documentation>Last name, company name if non- residential.</xs:documentation> </xs:annotation> </xs:element> <xs:element name="firstName" type="xs:string" minOccurs="0"> <xs:annotation> <xs:documentation>First name (if residential).</xs:documentation> </xs:annotation> </xs:element> <xs:element name="mName" type="xs:string" minOccurs="0"> <xs:annotation> <xs:documentation>Middle name or initial (if residential).</xs:documentation> </xs:annotation> </xs:element> <xs:element name="specialNeeds" type="xs:string" minOccurs="0"> <xs:annotation> <xs:documentation>Special service needs for the person (contact) are described; examples include life support, etc.</xs:documentation> </xs:annotation> </xs:element> <xs:element name="governmentID" type="xs:string" minOccurs="0"> <xs:annotation> <xs:documentation>Unique identifier for person relative to it's governing authority, for example a federal tax identifier (such as a Social Security number in the United States).</xs:documentation> </xs:annotation> </xs:element> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType>

Figure 32 : example for XSD generation for an Information Model Component ACC

EDF R&D


H-R49-2006-04284-EN


6.2.3. UML Information Model Extensions to XSD All extensions to the information model will be also generated following the same rules. For example, the ErpCivility extension will be generated in the ModelExtensions.xsd file associated to the namespace xmlns:CuSExt="CuS_EDF_Extensions".


<<Extension>>

<xs:complexType name="ErpCivility" mixed="false"> <xs:annotation> <xs:documentation>civility of a person (Mr, Miss, ... etc)</xs:documentation> </xs:annotation> <xs:complexContent mixed="false"> <xs:extension base="cim:Naming"> <xs:sequence> <xs:element name="civility" type="xs:string" minOccurs="0"> <xs:annotation> <xs:documentation>civility of a person (Mr, Miss, ... etc)</xs:documentation> </xs:annotation> </xs:element> </xs:sequence> </xs:extension> </xs:co plexContent> m</xs:complexType>

Figure 33 : example of XSD generation for the model extension ErpCivility

6.2.4. UML (Sub-)Contextual Model to XSD Now, we want to generate an XSD file containing the restrictions based on the information model components. All those contextual components will be generated in ContextualComponents.xsd (namespace xmlns:CuSRestrict="CuS_EDF_ContextualComponents" in our example).

The contextual data types will be generated in ContexualDataTypes.xsd (namespace xmlns:CuSDT="CuS_DataTypes" in our example). We are going to show the XSD generation for the CuS_ErpCivility.


<<Enumeration>>

<xs:simpleType name="Civility_enum"> <xs:restriction base="xs:string"> <xs:enumeration value="Mr"/> <xs:enumeration value="Mrs"/> <xs:enumeration value="Miss"/> </xs: striction> re</xs:simpleType>

<xs:complexType name="CuS_ErpCivility" mixed="false">

CuS_ErpCivilitycivility : Civility_enum

<<ABIE>>


<<Extension>>

<<Is based On>>

<xs:complexContent mixed="false"> <xs:restriction base="CuSExt:ErpCivility"> <xs:sequence> <xs:element name="civility" type="CuSDT:Civility_enum"> <xs:annotation> <xs:documentation>civility of a person (Mr, Miss, ...etc)</xs:documentation> </xs:annotation> </xs:element> </xs:sequence> </xs:restriction> </xs:co plexContent> m</xs:complexType>

Figure 34 : example of XSD generation for the contextual component CuS_ErpCivility You can notice that the <ABIE>CuS_ErpCivility contextual component is defined as a xs:restriction based on the ErpCivility CuSExt:ErpCivility. Then, you have the list of all restrictions. In this example, the property civility is restricted with the use of the contextual data type Civility_enum (<xs:element name="civility" type="CuSDT:Civility_enum">).

EDF R&D


H-R49-2006-04284-EN


This is also very important to notice that <ABIE>CuS_ErpCivility is really appearing as using data which are coming from an extension package (namespace prefix CuSExt) and not from the Information Model Package (namespace prefix cim). So we clearly see whether an information is an extension to the model.

We could have imagined other kinds of restrictions. For example, the postalCode property of <ACC>ErpAddress has a String data type restricted in <ABIE>Cus_ErpAddress as a five digit Integer (<xs:pattern value="[0-9]{5}"/>).

CuS_ErpAddressstreetNumber : StringstreetName : Stringcity : Stringcountry : StringpostalCode : Integer[5]

<<ABIE>>

ErpAddress<<ACC>>

<<Is based On>>

<xs:complexType name="CuS_ErpAddress" mixed="false"> <xs:complexContent mixed="false"> <xs:restriction base="cim:ErpAddress"> <xs:sequence> <xs:element name="streetNumber" type="xs:string"/> <xs:element name="streetName" type="xs:string"/> <xs:element name="city" type="xs:string"/> <xs:element name="country" type="xs:string" minOccurs="0"/> <xs:element name="postalCode"> <xs:annotation> <xs:documentation>Postal code for the address.</xs:documentation> </xs:annotation> <xs:simpleType> <xs:restriction base="xs:string"> <xs:pattern value="[0-9]{5}"/> </xs:restriction> </xs:simpleType> </xs:element> </xs:sequence> </xs:restriction> </xs:complexContent> </xs:complexType>

Figure 35 : example of the XSD generation of the CuS_ErpAddress Specifying <ABIE>CuS_ErpAddress as a contextual component based on the information model <ACC>ErpAddress component is generated at XSD level as <xs:restriction base="cim:ErpAddress">. So the XSD files are really expressing that this is a restriction based on the <ACC>ErpAddress coming from the cim namespace. This cim namespace represents the definition of our information model components.

EDF R&D


H-R49-2006-04284-EN


6.2.5. UML Message Assembly Model to XSD

6.2.5.1. profile (without instance interoperability) to XSD


<<ABIE>>



<<ABIE>>

1

0..1

1

0..1CuS_ErpPerson

<<ASBIE>>

CuS_Organisation

<<MessageLink>>

<xs:element name="CuS_Organisation"> <xs:complexType mixed="false"> <xs:complexContent mixed="false">

<xs:extension base="CuSRestrict:CuS_Organisation"> <xs:sequence> <xs:element name="CuS_ErpPerson" minOccurs="1"> <xs:complexType mixed="false"> <xs:complexContent mixed="false"> <xs:extension base="CuSRestrict:CuS_ErpPerson"> <xs:sequence minOccurs="1"> <xs:element name="" type=""/> </xs:sequence> </xs:complexContent> </xs:complexType> </xs:element> </xs:sequence> </xs:extension> </xs:complexContent> </ s:complexType> x</xs:element>

Figure 36 : example of XSD generation for a containment profile without instance interoperability

This is one way of generating elements and their types according to this basic profile and to XML NDR. But here the instances will bared the derived naming like “CuS_Organisation”, and not “Organisation”; doing that we will not have “instance interoperability”. Note that this XSD generation is perfectly right, here by using traceability we have also the link with the ACC of the Information Model. If we want to reach Instance Interoperability, we have to use some other rules.

EDF R&D


H-R49-2006-04284-EN


6.2.5.2. Instance interoperability profile to XSD

6.2.5.2.1.Basic XSD generation for Elements and types

Message Payload<<ABIE>>

1Organisation


<<ABIE>>

1

1


<<MessageLink>>

ErpPerson


<<ABIE>>

<xs:element name="Organisation"> <xs:complexType mixed="false"> <xs:complexContent mixed="false"> <xs:extension base="CuSRestrict:CuS_Organisation"> <xs:sequence> <xs:element name="ErpPerson" minOccurs="1"> <xs:complexType mixed="false"> <xs:complexContent mixed="false"> <xs:extension base="CuSRestrict:CuS_ErpPerson">

<xs:sequence minOccurs="1"> <xs:element name="" type=""/> </xs:sequence> </xs:complexContent> </xs:complexType> </xs:element> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> </xs:element>

Figure 37 : example of XSD generation for basic Containment The Elements and their types are defined in the RealMessage.xsd, according to XML NDR, except for rules R80 and 56, where association are elements and ABIE are complex types. For example, the <ABIE> CuS_Organisation is defined as a type with a restriction based on the information model component <ACC>Organisation. The <ASCCSubstitution> Organisation is generated as the <xs:element name="Organisation">. This element concatenates the CuS_Organisation ABIE Type (contextual) (<xs:extension base="CuSRestrict:CuS_Organisation">) with other elements such as the one corresponding to <ASCCSubstitution>ErpPerson.

So at XSD side, a <ASCCSubstitution> is the concatenation of:

• A restricted information model component. The name of this element is the same as the name of the information model association it is based on.

EDF R&D


H-R49-2006-04284-EN


• A list of elements based on the allowed associations in the UML information model. This list can be empty. So remember that you cannot add in the list, all the elements you would like to. This list of elements is coming from the restrictions you set on the associations between information model components.

EDF R&D


H-R49-2006-04284-EN


6.2.5.2.2.How to deal with ABIE being an association class?

firstName : String


<<ABIE>>

CuS_ErpPersonlastName : String

<<ABIE>>

CuS_Organisationname StringorganisationCode : String marketRole : MarketRole_enum

<<ABIE>>

1

1

1

1

ErpPerson

<<ASCCSubstitution>> OrganisationErpPersonRole

<<ASCC.ASCCSubstitution>>

<xs:element name="Organisation"> <xs:complexType mixed="false"> <xs:complexContent mixed="false"> <xs:extension base="CuSRestrict:CuS_Organisation"> <xs:sequence> <xs:element name="ErpPerson" minOccurs="1"> <xs:complexType mixed="false">

<xs:complexContent mixed="false"> <xs:extension base="CuSRestrict:CuS_ErpPerson"> <xs:sequence minOccurs="1"> <xs:element name="Organisation.ErpPersonRole" type="CuSRestrict:CuS_OrgErpPersonRole"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> </xs:element> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> </xs:element>

Figure 38 : example of XSD generation for the association class definition You can notice the way the association classes in the UML contextual message model are generated at XSD side. For example, the <ASCC.ASCCSubstitution>OrgErpPersonRole is generated as a property of the <ASCCSubstitution> ErpPerson. By doing it this way they in fact follow the standard XML NDR Rules.

EDF R&D


H-R49-2006-04284-EN


6.2.5.2.3.Full Instance Interoperability XSD generation for our example


<<Container>>

CuS_OrgErpPersonRoleroleType : OrgErpPersonRole_enum

<<Container>>


<<Container>> CuS_ErpTelephoneNumbercountryCode : Int[2]localNumber : Int[10]

<<Container>>


<<Container>>


<<Container>>

1

1

1

1

1

1

1

1

1

1

1

1

1

11

1


<<Enumeration>>OrgErpPersonRole_enum

contact

<<Enumeration>>


<<Enumeration>>

This is the UML Message Assembly Model seen in 5.2.4.

<xs:element name="Organisation"> <xs:complexType mixed="false"> <xs:complexContent mixed="false"> <xs:extension base="CuSRestrict:CuS_Organisation"> <xs:sequence> <xs:element name="ErpPerson" minOccurs="1"> <xs:complexType mixed="false"> <xs:complexContent mixed="false"> <xs:extension base="CuSRestrict:CuS_ErpPerson"> <xs:sequence minOccurs="1"> <xs:element name="Organisation.ErpPersonRole" type="CuSRestrict:CuS_OrgErpPersonRole"/> <xs:element name="ErpTelephoneNumber" type="CuSRestrict:CuS_ErpTelephoneNumber" minOccurs="1"/> <xs:element name="ErpCivility" type="CuSRestrict:CuS_ErpCivility" minOccurs="1"/> <xs:element name="ErpAddress" type="CuSRestrict:CuS_ErpAddress" minOccurs="1"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> </xs:element> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> </xs:element>

Figure 39 : full realMessage.xsd generation (XML Message Modeling Level)

EDF R&D


H-R49-2006-04284-EN


7. Consequences on improving traceability, reusability and instance interoperability

7.1. Traceability As you can see in §6.2.4, the traceability between a core component data and its use in a specific contextual data is totally expressed at XSD side in a way that standard XSD parsers can understand and validate (indeed it uses the xsd:restriction).

All the definition of contextual restrictions can be therefore validated with standard XML parsers against the information model being used as a shared semantic. The way the traceability is managed in this document differs from the way the UN/Cefact NDR is specifying it. Indeed, in the UN/Cefact NDR, the traceability is managed by writing XML data inside the <xs:annotation> XSD element. This annotation XSD element is not supposed to contain XML data but documentation and commentaries. In UN/Cefact NDR, those XML documentation data can contain some information such as the name of the ACC used to define the ABIE. The problem is that those UN/Cefact XML documentation data cannot be validated by standard XML parsers, and it needs additional programming.

7.2. Reusability The reusability is probably one of the most important features that UN/Cefact CCTS wanted to improve. Indeed the Core Component concept really appeared to ease the reusability of those core concepts in several business studies.

As you can see in §6.2.1, the way the different XSD files are generated facilitates the reusability of:

• Information model data in several different contextual models

• Contextual model data in several different messages

Indeed each modeling level has its equivalent at XSD side. So each XSD level can be imported and reused in a sub-level of modeling.

Therefore, for example, we could define several different messages based on the same contextual model. So each message model can add more restrictions on this contextual model.

We could also define several different contextual models sharing the same information model. For example, the CIM information model could be used to define one contextual model for the distribution, another one for the transmission, and another one for the power generation domain. Then inside each one of those contextual models, we could define some sub-contextual models for each business process study belonging to this specific domain (ex: distribution domain). Each time we introduce a new sub-context, we can only restrict the model of the previous context.

UN/Cefact is being approaching the point of view presented in this document for the modularity. For example, we can find in the UN/Cefact NDR document the following diagram.

EDF R&D


H-R49-2006-04284-EN


Figure 40 : UN/Cefact XSD modularity

You can see that this view is close to the one presented in this document (see §6.2.1) except that UN/Cefact NDR does not give yet the way to define:

• Extensions to an information model

• message sub-contextual model

• message assembly needs

EDF R&D


H-R49-2006-04284-EN


7.3. Instance Interoperability Interoperability facilitation is probably the most important item dealt in this document. It is presented after the two previous one (traceability and reusability) because this last feature is using them to gain more strength.

In order to better explain how the recommendations presented in this document are facilitating interoperability, we will use a small example of XML data based on the XSD definition seen in §6.2.5.2.3.


<<Container>>

CuS_OrgErpPersonRoleroleType : OrgErpPersonRole_enum

<<Container>>


<<Container>> CuS_ErpTelephoneNumbercountryCode : Int[2]localNumber : Int[10]

<<Container>>


<<Container>>


<<Container>>

1

1

1

1

1

1

1

1

1

1

1

1

1

11

1


<<Enumeration>>OrgErpPersonRole_enum

contact

<<Enumeration>>


<<Enumeration>>

See a larger image here 6.2.5.2.3.

<Organisation> <name>EDF</name> <organisationCode>456218ffd6s5</organisationCode> <marketRole>BalanceSupplier</marketRole> <ErpPerson> <lastName> Dupont</lastName> <firstName>Pierre</firstName> <Organisation.ErpPersonRole> <roleType>contact</roleType> </Organisation.ErpPersonRole> <ErpTelephoneNumber> <countryCode>33</countryCode> <localNumber>0000000000</localNumber> </ErpTelephoneNumber> <ErpCivility> <civility>Mr</civility> </ErpCivility> <ErpAddress> <streetNumber>33</streetNumber> <streetName>av des puits</streetName> <city>Paris</city> <country>France</country> <postalCode>75000</postalCode> </ErpAddress> </ErpPerson> </Organisation>

Figure 41 : XML instance respecting the XSD definition of the business example When we look at this XML instance, we can notice several consequences:

• This XML message instance is really giving the impression that we are browsing the UML information model. We have an Organisation containing some attributes name, organisationCode, marketRole. Then we have the ErpPerson component as a child of the Organisation component. But this XML message is also totally respecting all the business restrictions we specified. For example, the value of marketRole is here balanceSupplier. It cannot be something which is not into the Business Data Type enumeration MarketRole_enum (see §5.2.3).

• This XML message instance could be also validated against a generic XSD definition, which would not add business restrictions on the UML information model.

• Another consequence is at database side. Let us take an XML interface being able to know and understand the whole UML information model for a specific business domain (ex: the CIM model). For example, this XML interface could be a database interface. This database could contain the whole CIM information model as a database schema definition. We can expect that this XML interface could understand and store in the database all XML messages following the rules described in this document even the messages not defined yet. Indeed, the XML interface already knows all the potentiality of XML instance messages because it knows the whole information model used to build all XML messages. So, we could imagine a generic XML database interface being able to take as an argument any XML messages following those rules. This could really facilitate and automate interoperability between applications.

So we can sum up this idea with the following one: if we know the whole UML information model in a specific domain, we can know and understand all possible XML messages built using those recommendations and using this information model as a shared semantic.

Of course, this idea has still to be experienced with a real prototype but that could be a nice test for a future interoperability test at EIC.

EDF R&D


H-R49-2006-04284-EN


8. Conclusions

8.1. Main conclusions Before to start this UN/Cefact specification extension study, the main questions for us were:

• XML Instance Interoperability:

o what are the rules at UML and XSD side in order to have at the end a XML instance being able to be validated against a generic XSD (without restrictions upon the information model) as well as a restricted XSD (expressing our business needs added upon a generic information model like the CIM)? So as a consequence, a restricted XML message can be understood by another application dealing only with generic XML messages using the same components from the information model.

o What are the rules to have a XML instance giving the feeling that we are browsing the information model while reading this XML instance? So we wanted to have at XML instance side the same naming conventions and structures as the ones used in the information model.

• Traceability: What are the rules to keep track on the information model components used in our XML instance?

• Reusability: What are the rules giving a modularity raising the ability to reuse a component from a modeling level to another?

In order to do that:

• we found that in the spirit of CCTS, we should be able to express those concepts at UML level too.

• we express some needs for Message Assembly rules that lead to introduce some new concepts like <<ACCSubstitution>>.

• And to deal with CIM Model, we added some new concepts like <<ASCC.ASCC>> which provides means to deal with association class. Association classes are very important at UML information model level in order to improve semantic accuracy and to facilitate ASCC restriction process.

Basically, the core of the transformation is based on using complex properties (ASCC and ASBIE) to generate XSD elements naming rules and using Components (ACC and ABIE) to generate Complex Type for those XSD elements.

For Message Assembly rules we define several methods (Sequencing, grouping properties, traceability, reusability, instance interoperability) that should be taken into account for the “Message Assembly” UN/Cefact next specification. We did not describe all these methods, but we focus mainly on one which is the most complex one.

We found that for this Assembly Method, some XML rules are not adequate.

Based on the example we show, we are showing that UN/Cefact specifications are really relevant to our needs. We have also pointed out that CIM UML Model needs some modifications: like for association naming, or use of bidirectional associations.

We are aware that this is a first try, and first try might have some weakness and errors, especially in the CCTS interpretation and its representation using UML. In our example, we treated Aggregate Classes (ACC and ABIE) and Associations (ASCC and ASBIE) as if the two where two different pieces; but in CCTS, ASCC and ASBIE are part of ACC and ABIE. That is why at the end, in the XSD we do not have just restrictions but have also some extensions too. We intend to do another study, where we will take this into account.

EDF R&D


H-R49-2006-04284-EN


8.2. Some needed features for a future version

8.2.1. How to deal with UN/Cefact data types? The next thing that would be interesting for a future version of IEC CIM standards is to move to UN/Cefact DataTypes. It is still to be tested, but we think that the way the traceability is being taken care in this document between information model and contextual components “would work” with Core and Business Datatypes.

Indeed, a UN/Cefact data type has two kinds of attributes:

• Content: it is the main value of the property typed by this UN/Cefact data type. The value is instantiated in the content of the xsd:element corresponding to this property.

• Supplementary attributes: those attributes are instantiated in the attributes of the xsd:element corresponding to the property typed by this UN/Cefact data type.

The xsd:restriction to endorse the traceability should not be affected by the use of the UN/Cefact data types at XSD side. In our EDF R&D business studies based on the use of the CIM model, we did not use the UN/Cefact data types because the CIM is not yet compliant with UN/Cefact data types. So we would first need to make the CIM model compliant with the UN/Cefact data types.

8.2.2. How to deal with the sequence order of simple properties and complex properties at UML and XSD side?

When we build the UML Message Sub-Contextual Model/UML Message Assembly Model (see §5.2.3), we would need to be able to express the sequence order of all simple properties in a class as well as all complex properties which are containers in this modeling level.

For example, we could express that the lastName must be defined after the firstName in the ErpPerson container. We could also want to express that the ErpPerson must be defined after the ErpAddress definition inside the ErpPerson container.

Another way could be to choose a predefined rule like the alphabetical order for example. We could imagine many different rules for the sequence order. So we need to establish the sequence order rule we want for a specific business context. Those kind of rules are typically to be defined in a message assembly/syntax binding profile for our CCTS methodology proposed evolution (see §4.2.3).

Next CCTS version is considering the ability to manage sequence order.

8.2.3. How to deal with “Property Grouping” This has to be considered at Message Assembly level, because it is this way that a lot of Message Content are made right now. If we follow our full CTTS proposed evolution (see §4.2.3), it has to be defined in a new assembly/syntax binding profile.

EDF R&D


H-R49-2006-04284-EN


9. . Appendix A: Why association classes are so important?

9.1. Association Class What is an association class? It is a class that gives some extra information on an association, or in the Un/Cefact semantic, it will be a complex property of an association itself (but right now CCTS do not have this notion).

Let us take one example with the association between “Organisation” and “ErpPerson”.

Organisation(from TopLevel)

ErpPerson(from ERP_Support)


0..n0..n 0..n0..n

That covers in fact two relations:



0..n

0..n

+Organisation0..n

+ErpPerrson0..n

One is saying the kind of relation an Organisation have with an ErpPerson, and the other the kind of relation an ErpPerson have with an Organisation. Let us take one of these relations:


ErpPerson(from ERP_Support)0..n

+ErpPerrson

0..n

If now, we want to say that this relation is “active” or “pending”, or is true for a “time period”, or begins at a certain date, how could we do that? With an association class:

OrgErpPersonRole

status : StringstatusStartDate : AbsoluteDate

(from TopLevel)


ErpPerson(from ERP_Support)0..n

+ErpPerrson

0..n

So this is a first reason to use association classes. But we are going to see that there are others ones that are also important: expressing different kind of role one class is playing towards another one when they have a relation.

And, in our opinion, it will capture business analysts, architects and business modelers needs in a more accurate and consistent way.

9.2. Use Case Example So, at the information level, we have this relation between “Organisation” and “ErpPerson”.

EDF R&D


H-R49-2006-04284-EN


9.2.1. First Business case In a first business case, there is a need to express the fact that an “Organisation” have two kinds of people there are in contact with: “Financial Contact” and “Technical Contact”. One way of doing that is to create two new associations:



0..n

+TechnicalContact

0..n

0..n+FinancialContact

0..n

Figure 42 : Financial and Technical Contact associations

So in their very simple study, simple associations are specified with the association role TechnicalContact and FinancialContact.

9.2.2. Second business case Then later, another use case shows the need to have some other roles, besides the previous ones, like director and employee. So some new simple relations should be added.



0..n0..n

0..n+FinancialContact

0..n

0..n+Employee

0..n 0..n

+Director

0..n

+TechnicalContact

Figure 43 : Use Case Information Model

As you see, the final UML model contain four associations with two roles about a contact concept and two other roles about a hierarchy concept. But, a hierarchy concept is really different from a contact concept. If we want to capture all the semantic of the association, those concepts need to be defined at UML level: and here the use of an association class could be helpful.

9.2.3. Using association class to enhance modeling

OrgErpPersonRole

hierarchyRole : StringcontactRole : String

(from TopLevel)


ErpPerson(from ERP_Support)0..n0..nErpPerson

Figure 44 : final UML information model using association class

EDF R&D


H-R49-2006-04284-EN


As you can now see, this new UML information model is containing all the missing concepts (contactRole and hierarchyRole).

This new UML information model can now be shared between the two previous business studies.

For example, the second UML business study will be able to define the following UML contextual model based on this UML information model.

My_Organisation<<ABIE>>

My_ErpPerson<<ABIE>>

ErpPerson

my_OrgErpPersonRolehierarchyRole : HierarchyEnumcontactRole : ContactEnum

<<ABIE>>HierarchyEnumDirectorEmployee

<<Enumeration>>ContactEnum

FinancialContactTechnicalContact

<<Enumeration>>

Figure 45 : UML contextual model defining the different role values

So the Role Values are defined at contextual Model level by restricting the type of contactRole and hierarchyRole.

As you can see, using association class is pushing business architect, analysts and modelers to define UML models with a higher accuracy and consistency. Some other business studies could then reuse this UML information model to define UML contextual model containing other roles values. And each UML study is reusing the same UML information model.

9.3. Conclusions

9.3.1. Improving Accuracy and Consistency of the UML business modeling thanks to the use of association classes.

As you saw in the previous business example, the use of association classes are pushing business modelers to express all concepts. When we have more than one association between two classes, using simple associations is looking easier and quicker in a first step. But business modelers might not express all needed concepts using this modeling facility.

9.3.2. Better Compliancy with UN/Cefact CCTS methodology derivation process thanks to the use of association classes

As you saw, without association classes, each time we want to define a new role value (for example productContact in the contactRole), we have to Extend the UML information model by adding a new association having the role productContact that we want to define.

EDF R&D


H-R49-2006-04284-EN


Organisation<<ACC>>

ErpPerson<<ACC>>

0..n+TechnicalContact

0..n

0..n

+FinancialContact

0..n

0..n+Director

0..n

0..n

+Employee

0..n

Previous UML information model

ErpPerson<<ACC>>

Organisation<<ACC>>

0..n+TechnicalContact

0..n

0..n

+FinancialContact

0..n

0..n+Director

0..n

0..n

+Employee

0..n 0..n

+productContact

0..n

Extended UML information model to define a new role productContact.

Figure 46 : Extension to the UML information Model when defining a new role without using association class

Normally, a good UML information Model compliant with UN/Cefact CCTS spirit should enable to define those new role values by restricting the model at the contextual model level. And we should not be forced to extend the UML information model for those kinds of needs.

Indeed we only need to extend the UML information model if some concepts are missing. But here, the concepts of contactRole is not missing if we use association classes. What we want to do is only defining a new role value that the property contactRole could take. So here we only need, at UML contextual model, to define a restriction set on the contactRole property using an enumeration (technicalContact, financialContact, productContact).

Organisation<<ACC>>

ErpPerson<<ACC>>

0..n+ErpPerson

0..n

OrgErpPersonRolecontactRole : StringhierarchyRole : String

my_Organisation<<ABIE>>

my_ErpPerson<<ABIE>>

0..n+ErpPerson0..n

my_OrgErpPersonRolecontactRole : ContactEnumhierarchyRole : hierarchyRoleEnum

<<ABIE>>

ContactEnumfinancialContacttechnicalContactproductContact

<<Enumeration>>

hierarchyRoleEnumdirectoremployee

<<Enumeration>>

UML Information Model

UML Contextual Model

Restriction

definition

Model Extension!!

Figure 47 : Defining specific role by restricting the model thanks to the use association class