UN/CEFACT‘s Modeling Methodology (UMM 1.0) towards UMM 2.0 DissertantInnen Seminar – Mo, Christian Huemer Marco Zapletal Philipp Liegl Rainer Schuster

Outline  Introduction to UMM  UMM 1.0 by Example  A Business Service Interface for Business Transactions  Limitations of UMM 1.0  Modeling Business Documents  Call Behavior and Alternative Responses  UMM Choreographies and Business Entity States  Re-packaging the UMM  Multiparty Collaborations and Local Choreographies  Summary

We are going to talk about … UN/CEFACT‘s Modeling Methodology (UMM)

UN and e-Business?  To maintain international peace and security  To develop friendly relations among nations  To achieve international co-operation;

UN Layout Key

Application Goal: Exchange of business related data, independent of Software, Hardware and Communication Protocols EDI EDI Electronic Data Interchange (EDI)

United Nations Centre for Trade Facilitation and e-Business (UN/CEFACT] UN/EDIFACT ebXML UMM & CC UN Layout Key

Open-edi Reference Model – ISO Business Operational View Functional Service View Comply with Covered by Comply with Covered by Business aspects of business transactions Information technology aspects of business transactions Viewed as Transformed To Business Operational View Functional Service View Covered by Business aspects of business transactions Information technology aspects of business transactions as BUSINESS TRANSACTIONS BOV Related Standards FSV Related Standards UN/CEFACT`s Modeling Methodology (UMM) UN/EDIFACT Web Services ebXML

UN/CEFACT´s Modeling Methodology  Customizing UML for modeling inter-organizational processes  Concentrates on business semantics  Independent of the IT platform  Describes a choreography from a global perspective  UML Profile: Stereotypes, Tagged Values, Constraints on top of the UML Meta Model BDV Business Domain View BRV Business Requirement View BTV Business Transaction View UMM BSV Business Service View

Outline  Introduction to UMM  UMM 1.0 by Example  A Business Service Interface for Business Transactions  Limitations of UMM 1.0  Modeling Business Documents  Call Behavior and Alternative Responses  UMM Choreographies and Business Entity States  Re-packaging the UMM  Multiparty Collaborations and Local Choreographies  Summary

UN/CEFACT‘s Modeling Methodology (UMM)  Customizing UML for modeling B2B  Concentrates on business semantics  Independent of the IT platform  Describes a choreography from a global perspective  UML Profile: Stereotypes, Tagged Values, Constraints on top of the UML Meta Model –~ 40 stereotypes defined in the meta model UMM BDV Business Domain View BRV Business Requirements View BTV Business Transaction View

Import Authority Export Authority UMM by example  European crossborder waste management NotifierNotifiee Announce Waste Transport Announce Transport Arrival

Top-level UMM Packages >

UMM by example - BRV >

> Importer Export Authority Import Authority Exporter UMM by example – Business Partner

UMM by example - BRV Subview: CollaborationRealizationView

Top-level UMM Packages >

UMM by example - BTV BTUC BCUC >

The UMM Add-In  First prototypical implementation which supports the UMM approach  Developed by the University of Vienna in cooperation with the Research Studios Austria  Available for free from the project’s website –  Extension of the Enterprise Architect  Developed in C#  Current version: 0.8.2

UMM Add-In Overview

> UMM-specific toolbar Requirements Engineering – UMM Worksheets

Valid? [yes] [no] UMM Add-In – BPEL/BPSS Generator Validating UMM Model Semi-automatic generation of UMM artifacts Transformation into Choreography Languages UMM Validation

Outline  Introduction to UMM  UMM 1.0 by Example  A Business Service Interface for Business Transactions  Limitations of UMM 1.0  Modeling Business Documents  Call Behavior and Alternative Responses  UMM Choreographies and Business Entity States  Re-packaging the UMM  Multiparty Collaborations and Local Choreographies  Summary

[Control Fail] [Success] > Business Transaction > : Buyer : Seller :PurchaseOrder Envelope :OrderResponse Envelope place order process order isConfidential: no isTamperProof: yes isAuthenticated: yes isConfidential: no isTamperProof: yes isAuthenticated: yes timeToRespond: 24 hrs timeToAcknowledgeReceipt: 1 hrs timeToAcknowledgeProcessing: 4 hrs isAuthoriztionRequired: yes isNonRepudiationRequired: yes isNonRepudiationOfReceiptRequired: yes isIntelligibleCheckRequired: yes retryCount: 3 timeToAcknowledgeReceipt: 2 hrs timeToAcknowledgeProcessing: 8 hrs isAuthoriztionRequired: yes isNonRepudiationRequired: yes isNonRepudiationOfReceiptRequired: yes isIntelligibleCheckRequired: yes

Old Business Service View :BuyerService :SellerService PurchaseOrderEnvelope AcknowledgmentOfReceipt AcknowledgmentOfProcessing OrderResponseEnvelope

State Machines  Describes the Business Service Interface of a participating partner  Unambiguous definition on how to react on –Incoming messages –Messeages expected, but not received  Resulting State Machines: –The state machine of the initiatorstate machine –The state machine of the responderstate machine

Outline  Introduction to UMM  UMM 1.0 by Example  A Business Service Interface for Business Transactions  Limitations of UMM 1.0  Modeling Business Documents  Call Behavior and Alternative Responses  UMM Choreographies and Business Entity States  Re-packaging the UMM  Multiparty Collaborations and Local Choreographies  Summary

Limitation 1  Vague guidelines on modeling business documents

Limitation 2  Work-around to support call behavior in UML 1.4  >

Limitation 3  Inability to model alternative responses

Limitation 4  Flow may be well interpreted by humans  Fails to give an unambiguous machine-processable definition

Limitation 5  Split of strongly related artifacts into different packages

Limitation 6  No multi-party choreographies  No nested business transactions

Outline  Introduction to UMM  UMM 1.0 by Example  A Business Service Interface for Business Transactions  Limitations of UMM 1.0  Modeling Business Documents  Call Behavior and Alternative Responses  UMM Choreographies and Business Entity States  Re-packaging the UMM  Multiparty Collaborations and Local Choreographies  Summary

Motivation for standardizing the exchanged data SOAP message Order processing of enterprise X request for quote place order check order status Enterprise Application Customer Y Enterprise Application WSDL SOAP message UDDI registry

Motivation for standardizing the exchanged data SOAP message Order processing of enterprise X request for quote place order check order status Enterprise Application Customer Y Enterprise Application WSDL SOAP message UDDI registry Enterprise Application WSDL SOAP Message SOAP Body SOAP Header Message Body

Motivation  Problem domain –Business documents exchanged in a business process in a service oriented context  UN/CEFACT provides a generic solution –Core Components Technical Specification (CCTS) –Almost no tool support possible – CCTS are standardizes as spread sheets  UML Profile for Core Components –Seamless integration into UML modeling tools possible –Seamless integration into e.g. process modeling specific models possible

Harmonizing the exchanged data  Known standardization efforts –UN/EDIFACT –XML based solutions (RosettaNet)  Known issues of these efforts –Multitude of different and competing standards –Inclusion of every possible element that may be required – strong overhead –Changes in the transfer syntax would require a complete reegineering  Solution –Platform independent resuable building blocks for creating shared libraries of business documents developed by UN/CEFACT

Core Components  Are the central building blocks of the Core Component Technical Specification  Platform independent  Used to create shared libraries of interoperable business documents  The ontological base of the CCTS is the United Nations Trade Data Element Dictionary (UN/TDED)  Initially started as part of ebXML standards suite  Now a dedicated project independent of ebXML

Core Component (CC) example  No business context  Independent of industry or domain ACCAggregate Core Component BCCBasic Core Component ASCCAssociation Core Component

Business Information Entity (BIE) example  Core Components in a specific business context (e.g. travel industry)  BIEs have a specific business semantic  Qualifiers (US_) help to define and differentiate a BIE from ist associated CC and other BIEs ABIEAggregate Busines Information Entity BBIEBasic Business Information Entity ASBIEAssociation Business Information Entity

By introducing the business context core components become business information entities Core Components (CC) Business Information Entities (BIE) BIEs are derived from CCs by restriction

Dependency between Core Components and Business Information Entites

Data Types  Qualified Data Types (QDT) are derived from Core Data Types (CDT) by restriction  Business Information Entities use QDT and CDT  Core Components use only CDT

The core component meta model

A UML Profile for Core Components  Flaws of the Core Components Technical Specification –Standardization process of Core Components is based on spread sheets –No direct integration into modeling tools possible  UML Profile for Core Components –Independent project based on the CCTS –Set of stereotypes, tagged values and OCL constraints –Can be integrated into a modeling tool of choice –Proof of concept based on UML modeling tool Enterprise Architect –UML class diagrams are used for the modeling of Core Components

UML profile for Core Components - Stereotypes

Assembling a business document using the different libraries of the UML profile for Core Components Business Library DOCLibrary BIELibrary CCLibrary QDTLibrary CDTLibrary ENUMLibrary PRIMLibrary Business document

Derivation of XSD artifacts […] Core Component Model XSD Schema generator Naming and Design Rules

Conclusion and Outlook  The UML profile for core components provides a method to model exchanged information –independent of the platform –independent of the transfer syntax –in shared libraries –on a common ontological base –derive different platform specific artifacts  Future work –Develop a new UML profile for CCTS 3.0 (UPCC) –Adaptation of the XSD schema generator –Build a repository to store and retrieve existing ABIE and data type libraries

Outline  Introduction to UMM  UMM 1.0 by Example  A Business Service Interface for Business Transactions  Limitations of UMM 1.0  Modeling Business Documents  Call Behavior and Alternative Responses  UMM Choreographies and Business Entity States  Re-packaging the UMM  Multiparty Collaborations and Local Choreographies  Summary

 UML 2 provides the concept of call behavior actions  eliminates the maps to‘s  > Eliminating Limitation 2 by Call Behavior Activity

Eliminating Limitation 3 – Allowing multiple responses  Differing business intentions should be expressed using different response document types  Multiple responses denoted via the object pin syntax

XOR relation between the possible response document types  In case multiple documents are sent – parameter sets are used to implement an XOR realtionship –there is always a 1:1 relationship between a document flow and its enclosing parameter set

Limitation 4 – Only human-comprehensible interdependencies  The content of a response document needs to be examined to decide on the positive or negative outcome of a business transaction. –Using different response business document types alleviates this problem  The actual business document type decides on the end state of a business transaction. –However, there exists no formal relationship between a business document type and the semantically corresponding final state  The business collaboration protocol is guarded by the outcome of business transactions. –However, there is no explicit reference between the transition guards and the business transaction final states.

Limitation 4 – Only human-comprehensible interdependencies

context NotifyWasteTransport inv NegativeResponse: self.input−>one (x|x.isTypeOf WasteMovementRejectionEnvelope) and x <> null) context NotifyWasteTransport inv PositiveResponse: self.input−>one (x|x.isTypeOf (WasteMovementAcceptanceEnvelope) and x <> null) 1 2 Eliminating Limitation 4 – Step 1 Binding final states to business document types 2 1

Eliminating Limitation 4 – Step 2 Introducing Business Entity States in BT  The execution of a business transaction changes the state of a business entity

Eliminating Limitation 4 – Step 3 Business Entity States as Guard Conditions in BCP  The flow of a business collaboration protocol is unambiguously governed by business entity states act Manage Waste Transport - with States «BusinessTransactionActivity» :AnnounceWasteTransport «BusinessTransactionActivity» :AnnounceTransportArrival Success Failure [WasteTransport.oclInState(rejected)] [WasteTransport.oclInState(accepted)]

Conclusion  Showed the benefits of the transition from UML to UML 2 –eliminating meta model workarounds  Added the possibility to explicitly model different business intentions using multiple response document types  Formally bound business document types to business transaction final states and those in turn to guard conditions in a business collaboration protocol –required for a MDA-like approach

Outline  Introduction to UMM  UMM 1.0 by Example  A Business Service Interface for Business Transactions  Limitations of UMM 1.0  Modeling Business Documents  Call Behavior and Alternative Responses  UMM Choreographies and Business Entity States  Re-packaging the UMM  Multiparty Collaborations and Local Choreographies  Summary

> BusinessProcessActivityGraph > > (2 x) > > (2+ x) > > (2+ x) > Other Folders From UML Profile for CC

Waste Management: UMM 2

Outline  Introduction to UMM  UMM 1.0 by Example  A Business Service Interface for Business Transactions  Limitations of UMM 1.0  Modeling Business Documents  Call Behavior and Alternative Responses  UMM Choreographies and Business Entity States  Re-packaging the UMM  Multiparty Collaborations and Local Choreographies  Summary

Multi-party Collaboration

Multiple Bi-lateral Collaborations > OrderFromFirmQuote >

> of a Wholesaler (1) Interaction with Retailer > calculate quote > act on purchase order [Quote.provided] [Order.accepted][Order.rejected] [Quote.refused] Success Failure

> of a Wholesaler (2) Interaction with Retailer > request credit check

> of a Wholesaler (3) Interaction with Retailer > calculate quote > act on purchase order [Quote.provided] [Order.accepted][Order.rejected] [Quote.refused] Success Failure Interaction with Retailer > request credit check > :request credit check

Interaction with Retailer

Outline  Introduction to UMM  UMM 1.0 by Example  A Business Service Interface for Business Transactions  Limitations of UMM 1.0  Modeling Business Documents  Call Behavior and Alternative Responses  UMM Choreographies and Business Entity States  Re-packaging the UMM  Multiparty Collaborations and Local Choreographies  Summary

Summary ……

Techniques & Methodologies Group