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

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

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

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

5. ................................................. 5 UN Layout Key

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

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

8. ................................................. 8 Open-edi Reference Model – ISO 14662 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

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

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

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

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

13. ................................................. 13 Top-level UMM Packages >

14. ................................................. 14 UMM by example - BRV >

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

16. ................................................. 16 UMM by example - BRV Subview: CollaborationRealizationView

17. ................................................. 17 Top-level UMM Packages >

18. ................................................. 18 UMM by example - BTV BTUC BCUC >

19. ................................................. 19 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 –http://ummaddin.researchstudio.at  Extension of the Enterprise Architect  Developed in C#  Current version: 0.8.2

20. ................................................. 20 UMM Add-In Overview

21. ................................................. 21 > UMM-specific toolbar Requirements Engineering – UMM Worksheets

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

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

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

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

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

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

29. ................................................. 29 Limitation 1  Vague guidelines on modeling business documents

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

31. ................................................. 31 Limitation 3  Inability to model alternative responses

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

33. ................................................. 33 Limitation 5  Split of strongly related artifacts into different packages

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

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

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

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

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

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

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

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

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

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

44. ................................................. 44 Dependency between Core Components and Business Information Entites

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

46. ................................................. 46 The core component meta model

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

48. ................................................. 48 UML profile for Core Components - Stereotypes

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

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

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

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

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

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

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

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

57. ................................................. 57 Limitation 4 – Only human-comprehensible interdependencies

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

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

60. ................................................. 60 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)]

61. ................................................. 61 Conclusion  Showed the benefits of the transition from UML 1.4.2 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

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

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

64. ................................................. 64 Waste Management: UMM 2

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

66. ................................................. 66 Multi-party Collaboration

67. ................................................. 67 Multiple Bi-lateral Collaborations > OrderFromFirmQuote >

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

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

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

71. Interaction with Retailer

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

73. ................................................. 73 Summary ……

74. ................................................. 74 Techniques & Methodologies Group http://www.untmg.org http://www.umm-dev.org