Ksenia Wahler of the IBM Zurich Research lab presented the first paper in the Modelling Paradigms & Issues section, on Predicting Coupling of Object-Centric Business Process Implementations, co-authored by Jochen Kuester.
Although activity-centric approaches are in the mainstream — e.g., BPMN for modeling and BPEL for implementation — object-centric approaches are emerging. The main principles of object-centric approaches are that process logic is distributed among concurrently running components, each component represents a life cycle of a particular object, component interaction ensures that overall logic is correctly implemented.
They are using Business State Machines (BSM) in IBM WebSphere Integration Developer to model this: object-centric modeling is offered as an alternative to BPEL for service orchestration. It uses finite state automation, tailored for execution in a service-oriented environment, with event-condition-action transitions. The advantages of this approach is that it is distributable, adaptable, and maintainable. However, this works when objects are independent, but this is rarely the case; hence the research into the management of coupling of objects. What they found is that rather than using a unidirectional mapping from the activity-centric view to the object-centric implementation, wherein the models can get out of sync, their approach is to feed back from any changes in the object-centric implementation to the process model. They needed to establish a coupling metric in order to asses the coupling density of the object model, as well as develop the mapping from activity-centric process models to object life cycle components, which they have based on workflow patterns.
She showed examples of translation from activity-centric to object-centric models: starting with a BPMN process model, consider the objects for which each activity is changing the state, and re-model to show the state changes for each object and the interactions between the objects based on their state changes. Each state-changing object becomes a component, and interactions between objects in terms of control handovers and decision notifications become wires (connections) between components in the assembly model. The degree of coupling is calculated from the interactions between the components, and a threshold can be set for the maximum acceptable degree of coupling. Objects with a high degree of coupling may be candidates for merging into a single life cycle, or may be targeted for refactoring (actually not true refactoring since it doesn’t preserve behavior; more like simplifying) the process model in order to reduce control handovers and decision notifications.
This type of object-centric approach is new to me, and although it is starting to make sense, I’m not sure that these notes will make sense to anyone else. It’s not clear (and the speaker couldn’t really clarify) the benefit of using this approach over an activity-centric approach.