1. The Joint UML for EDOC Submission
ad/
Submitters:
CBOP, Data Access Technologies, DSTC, EDS, Fujitsu, IBM, Iona Technologies, OPEN-IT, Sun Microsystems, Unisys
Supporting companies:
Hitachi, Netaccount, SINTEF …

2. Agenda Introduction to UML for EDOC
Vision and Rationale
Submission structure, RFP Requirements
Platform Independent Modeling - ECA
CCA Profile
Entities Profile
Events Profile
Business Process Profile
Relationships Profile
Patterns
Platform Specific Modeling
EJB, FCM, MOF
Technology Mappings
Summary, RFP Requirements - Discussion

3. EDOC Vision
Simplify the development of component based Enterprise (EDOC) systems by means of a modeling framework, based on UML 1.4 and conforming to the OMG Model Driven Architecture.
Provide a platform independent, recursive collaboration based modeling approach that can be used at different levels of granularity and different degrees of coupling, for both business and systems modeling.

4. EDOC Key RFP Requirements
Modelling framework for enterprise distributed object computing systems:
Based on UML 1.4
System operation directly relatable to business processes
Models driven by business requirements
Mappable to different platforms (incl. CORBA )
Specifically, support modelling of:
Business entities
Business processes
Business rules
Business events.

5. Submission Structure

6. Using RM-ODP viewpoints
Enterprise viewpoint
(CCA, Business Processes, Entities, Relationships, Events)
Information viewpoint
(Entities, Events, Relationships)
(CCA, Entities, Events)
Computational viewpoint
Technology viewpoint
(UML for J2EE/EJB/JMS, CORBA 3/CCM, COM, SOAP, ebXML)
Part I:Technology
Specific Models
Part II:
ECA to
technology
mappings
Part I: ECA
(Technology abstraction: FCM)
Engineering viewpoint
Part I: Patterns -
applied to all viewpoints

7. Four general categories of ProcessComponent

8. The Internet Computing Model
Portals
Business
Party
Business
Party
Collaboration of independent entities
Document exchange over internet technologies
Large grain interactions, not “method calls”
No required infrastructure *
Long lived business processes
Business transactions
Not technical transactions

9. ECA “Pattern” for the MDA Platform Independent Models
Events
Entities
Process
CCA
Relationships
Integration -viewpoints
Patterns
Platform Independent Models
Technology mappings
Platform Independent Models
Platform Specific Models
FCM
MOM
ebXML
CORBA
COM
EJB
etc

10. Platform Independent Modeling
The Enterprise Collaboration Architecture

11. Component Collaboration Architecture
CCA
Component Collaboration Architecture
Collaborative process component specification for ECA

12. The Marketplace Example
Order
Conformation
Shipped
Process
Complete
Mechanics Are Us
Buyer
Acme Industries
Seller
Status
Ship Req
Physical
Delivery
Shipped
Delivered
GetItThere Freight
Shipper

13. The Seller’s Detail Event Order Processing Shipping Receivables Order
Conformation
Shipped
Shipping
Event
Ship Req
Receivables
Shipped
Delivered

14. The Buyer’s Detail Process DataFlow Process DataFlow
Supplier Evaluation
Order
Conformation
Process DataFlow
Shipped
Order
Process DataFlow
Ship Req
Receive Goods
Shipped
Delivered

15. Structure + Composition + Choreography
Specification of CCA
Structure +
Composition +
Choreography

16. Parts of a CCA Specification
Structure of process components and protocols
Process components, ports, protocols and documents
Class Diagram or CCA Notation
Composition of process components
How components are used to specify components
Collaboration diagram or CCA Notation
Choreography
Ordering of flows and protocols in and between process components
Activity Diagram

17. Process Component
A CCA Process Component defines a configurable behavioral unit that can be composed in a particular way
They can be logical or physical, concrete or abstract
They can represent anything from a business partner in a B2B exchange to a fine-grain computation
Process Components can be used to compose other process components, recursively
CCA is intended to be specialized, as a core architecture for process, entities and events at multiple levels of granularity
CCA is compatible with the ebXML Business Process Specification Schema which specifies B2B collaborations
Extends real-time capsule model

18. The Community Process
Identify a “community process”, the roles and interactions
Using CCA Notation

19. Component structure Component structure Defines the “outside”
Contract of a component

20. Meta Model for Structure
Key Point:
Process Components have ports
That either initiate or respond
To a protocol or flow

21. Protocol Example
Specification of a protocol

22. Meta Model for Protocol

23. Choreography of Protocol

24. Object Interfaces Use standard interface notation
Are a subtype of “Protocol” in the MetaModel
Allow modeling of and integration with classical and/or existing objects

25. Composition Composition defines the “inside” of a component
Use of an interface
Composition defines
the “inside” of a
component

26. Composition MetaModel

27. Properties Properties make process components configurable
They can be reset when a component is used – in a composition or at deployment time

28. ECA Entity Profile
The model of things

29. Sample Information Model

30. MetaModel for Information Model

31. Adding Entities Entities are added to manage entity data
Entity Roles are managers that provides a view of the same identity in another context
The Entities have ports for managing and accessing the entities
Non-entities which are owned by (aggregate into) an entity are managed by the entity

32. Entity Meta Model

33. ECA Business Events
The model of when…

34. Event Based Business Processes
Rules
Business
Services
Business Process
Business Events
Business Actions
Business Entity

35. Event Based Business Processes
Business Events
Business Process
Business Entity
Business
Rules
Business Actions
Business
Rules
Event Notification
Business Process
Business Events
Business Actions
Business Entity

36. Point to Point Notification
App
Business Process
Business Entity
Business
Rules
Business Events
Business Actions
App
Business Process
Business Entity
Business
Rules
Business Events
Business Actions
Event Notifications
App
Business Process
Business Entity
Business
Rules
Business Events
Business Actions
App
Business Process
Business Entity
Business
Rules
Business Events
Business Actions

37. Pub/Sub Notification Pub/Sub Loose Coupling App Business Process
Business Entity
Business
Rules
Business Events
Business Actions
App
Business Process
Business Entity
Business
Rules
Business Events
Business Actions
Pub/Sub
App
Business Process
Business Entity
Business
Rules
Business Events
Business Actions
App
Business Process
Business Entity
Business
Rules
Business Events
Business Actions
Loose Coupling

38. PubSub Package

39. Event Package

40. Putting it all together
Business
Rules
Business Process
Business Events
Business Actions
Business Entity

41. Event Example

42. Summary of Advantages Recursive decomposition & assembly Trace ability
Automating the development process
Loose coupling
Technology Independence
Enabling a business component marketplace
Simplicity through abstraction

43. Business Process Profile
how things are coordinated

44. Business Processes Specialize CCA Activity-centric view of a Process
Express
Complex temporal and data dependencies between business activities
Iteration of activities
Alternative required Inputs and Outputs of activities
Roles related to performers, artifacts and responsible parties for activities

45. The Business Process ConceptsCT C A
PR1 RP B AR
PR2

46. ProcessComponent Specialization
CompoundTask is a special ProcessComponent
Its Ports represent the type of an Activity
Its Composition arranges Activities in a dependency graph
Activity is a special ComponentUsage
Its MultiPort usages contain ProcessPortConnectors (ProcessFlowPort usages)
DataFlows between these Connectors express dependencies between Activities

47. Metamodel for BP ComponentsCT B A C RP
PR2 AR
PR1
Activity

48. BusinessProcess and BusinessProcessEntity
A BusinessProcess
Exposes arbitrary Ports (outside)
which define interfaces, operations, events for composition using CCA
Its Composition (inside) is restricted to containing Activities and DataFlows
A BusinessProcessEntity
Is a BusinessProcess whose instances are uniquely identifiable

49. Port Types and Semantics
ProcessMultiPorts specialize CCA Multiports
They act as correlators for data from many sources
May be synchronous (required before starting an Activity)
or asynchronous (accepted by Activity during execution)
ProcessFlowPorts specialize CCA FlowPorts
Multiplicity indicates how many values are required to enable containing Multiport
3 concrete kinds of ProcessMultiPort
InputGroup – alternative data sets required to begin an Activity
OutputGroup – alternative Activity result data sets
ExceptionGroup – abnormal Activity results

50. ProcessPortConnector
Metamodel for BP Ports
ProcessPortConnector
DataFlow CT C A
PR1 RP B AR
PR2

51. ProcessPortConnector
Metamodel for BP Ports
ProcessPortConnector
DataFlow CT C A
PR1 RP B AR
PR2

52. Data Flows DataFlows are special CCA Connections
Uni-directional between ProcessFlowPorts
DataFlows indicate
data dependency & transmit values at run-time, or
temporal dependency (aka control flow)

53. Process Roles
ProcessRoles are placeholders for the components that an Activity needs to do its work
Contain SelectionRules and/or CreationRules
these are search expressions / factory parameters to bind to objects at run-time
Three kinds of Roles
Performer - does the job of the Activity
Artifact – is a resource needed by the Performer
ResponsibleParty - authorizes the Activity

54. Metamodel for Process RolesCT B A C RP
PR2 AR
PR1

55. Process Patterns The basic model elements
ProcessMultiPorts
CompoundTasks
Activities
DataFlows
Are used to define useful patterns for processes
PreConditions and PostConditions
Timers and ProcessTerminators
Loops (while, for, repeat)
MultiTask - which spawns parallel Activities for each value in a collection Input

56. Interactions between Interfaces and Process Definitions
BusinessProcesses are
Roots of process definition graphs
CCA “Interface” ProcessComponents on the outside
CompoundTask Compositions on the inside
Gateway from the component world into the process definition world
ProcessRoles are
Leaves of a process definition graph
Bindings from Activities to “Interface” ProcessComponents which perform their work
Gateway from the process definition world into the component world

57. Relationships Profile
useful associations and dependencies

58. Relationships Profile
Enables non-binary aggregations
Defines useful association and dependency stereotypes

59. Aggregation Relationships
<<Aggregation>> is non-binary “black diamond” or “white diamond” whole/part association
4 more constrained aggregations are defined:
<<Assembly>> is an aggregation where the whole cannot exist without its parts
<<Subordination>> is an aggregation where the parts cannotb exist without the whole
<<Packet>> is an aggregation where the parts or the whole may exist independently
<<List>> is an aggregation where both the parts and the whole must exist in order to be valid (assembly and subordination)

60. Dependency Relationships
<<AbstractReference>> defines a dependency between a maintained instance whose properties are partly derived from a referenced instance
2 Concrete reference kinds are defined
<<Reference>> is a dependency indicating that a maintained instance has properties derived from a referenced instance
Whenever a property of the referenced element changes, the properties of the maintained element must be examined and possibly changed.
<<ReferenceForCreate>> is a dependency indicating that at creation time a maintained instance has properties derived from a referenced instance, but thereafter they are independent

61. reusing parameterized designs
Patterns Profile
reusing parameterized designs

62. Patterns Profile Profiles UML Parameterized Collaborations
Based on Business Function Object Patterns (BFOP)
Multi-Layer
Based on Catalysis Approach
Adds stereotypes for
Named Patterns
Inheritance
Composition
Pattern Binding with renaming
The proposed UML Profile for EDOC is designed to provide standard means, Business Function Object Patterns (BFOP), for expressing object models using UML package notation together with the mechanisms for applying patterns that are required to describe models.
Successful implementation of an enterprise computing system requires that the system operation to be directly related to the business processes it supports. Reusable standard models are required in order to build good object models for EDOC systems.
Standard models have Business Entities Objects, Business Processes Objects, Business Event Objects and Business Rules Objects of ECA. They also include a set of common and reusable patterns of relationship properties that occur in business modeling. BFOP is being developed to achieve this objective.
When a composite pattern is granular enough to include implementation details, and it is possible to use it to describe a component concept such as CCA, each pattern package can be implemented with real components instead of unfolding it into a component pattern. [ST-B1]In short, the proposed pattern concept and mechanism can be applied to the components based development that is required in EDOC.

63. Applying Simple Pattern
A [t1/tt1] P A1
applying s2
<A> B m2 s1 t1
Unfolding and Renaming m1
Constraint/Operation B A1
tt1 s1 s2 m1 m2

64. Applying Inherited Pattern
<B1> A3
Constraint/Operation
unfolding
Applying P1 A1 B1 P2 A3 B2 P1 A1 B1
unfolding
<A2> B2
Constraint/Operation A3 B2

65. Applying Composite PatternB1 C3 C4
Constraint/Operation
Constraint/Operation
unfolding P3 P1 P2
applying C1 C2 P1 P2 C4 C1 C2
<C3>
unfolding
Constraint/Operation A1 C4 B1

66. Patterns: Buyer/Seller
Inheritance
Composition

67. Patterns: Buyer/Seller
Applying
Unfolding

68. Platform Specific Modeling
EJB, FCM, MOF
Technology mappings from EDOC to Distributed Component and Message Flow Platform Specific Models
EDOC to J2EE/EJB mapping
EDOC to CORBA/CCM mapping
EDOC Business Process to FCM mapping
EDOC Business Process to CORBA mappinG

69. EJB, Java Profile – and JSR-26 “UML for EJB”
EJB is an implementation technology for distributed components
JSR-26 provides the UML Profile for EJB
EDOC provides
The EJB metamodel for this profile
The Java metamodel to support the EJB metamodel
Work in progress to map between the metamodel and the JSR-26 Profile

70. FCM – Flow Composition Model
General purpose model describing flows of information between application components enabling
Breakdown of complex acctions into simple flow components
Composition of simple entities into higher level flow models
Layer of abstraction just above middleware technology
WSDL, messaging, workflow
Mappings to FCM
EDOC: Business Process Profile
EAI: messaging technologies

71. UML Profile for MOF
The MOF Profile describes how to normatively express MOF models using UML.
Used by this submission to express the MOF models in the EDOC Specification
2-way transformation between UML and MOF for
Designing metamodels with UML (UML to MOF)
Viewing metamodels with UML (MOF to UML)
Expressed as tables showing:
The mappings of element types
Detailed mapping descriptions for individual element types
Guidelines for MOF modeling using UML

72. Part II - Supporting Annexes
Annex A - Procurement, Buyer/Seller example
Annex B - Meeting Room example
Annex C - Hospital example
Annex D - Examples of Patterns
Annex E - Technology mappings from EDOC to Distributed Component and Message Flow Platform Specific Models
XMI, DTD files

73. Introduction to EDOC and Platform Specific Models
Technology mappings from EDOC to Distributed Component and Message Flow Platform Specific Models
Introduction to EDOC and Platform Specific Models
Principal Platform Specific Models
Mapping from EDOC to J2EE/EJB
Mapping from EDOC to CORBA/CCM
Mapping from EDOC Business Process profile to CORBA
Mapping from EDOC Business Process profile to FCM

74. Abstract Technology Model
Deferred
Synch request
Naming service
Persistence service
Server
Components
Message
Transaction
service
Concurrency
XML
Synchron.
request
Event - publish &
subscribe
Data services &
Legacy systems
Shared Business
Services
User services
(application/process)
Interaction/Pres
services
Trading service
Security
Workflow
Streaming
Integration service
User Interface
Document model
Web interaction
System/Use Mngt

75. Computational viewpoint

76. Computational viewpoint
Protocol derived from a “traditional” interface

77. Mapping from EDOC to EJB

78. Technology viewpoint (EJB)

79. Mapping from EDOC to Corba/CCM

80. Mapping from EDOC Business Process
To CORBA - based on mapping to Workflow service elements
To CORBA -extended using Notification-based mapping
To CORBA - alternative using Interface-based mapping
To FCM- the Flow Composition Model

81. Wrap-up

82. The EDOC vision
A MOF model and a UML profile sufficient to support seamless, robust and consistent specification of all elements of the life cycle of an enterprise system
Enable the design, integration and subsequent evolution of enterprise systems
Links business concepts to system implementation by using same modeling concepts on multiple levels
Integrate commercial transactions, business processes and distributed object applications
Insulate business system specifications from technological idiosyncrasies
Support the development of specialized tools to improve the quality, cost and adaptability of business systems
Enable a business system components marketplace

83. Summary: Mandatory Requirements
Specification of Business Process objects (R3)
Modeling of Business Processes, Entities, Rules and Events (R2)
Specification of Relationships (R4)
Component modeling (R1)
MOF alignment (R5)
Proof of concept of Profile (R6)
Proof of concept of Mappability (R7)

84. We need a review team – to report by (Toronto – 3 weeks)
Call for Volunteers
We need a review team – to report by (Toronto – 3 weeks)

85. Tomorrow – UML4EDOC “Tutorial”
North Shore B
See the ships -
meet the men
(and women)

86. Questions?