Business Objects and Object Life Cycles - Researcher - IBM

© 2013 IBM Corporation

Business-Driven Software EngineeringLecture 9 – Business Objects and Object Life Cycles

Jochen Küster [email protected]

IBM Research – ZurichProcess Management Technologies

© 2013 IBM Corporation2


Dr. Jochen Küster | BDSE 2013

Agenda

� Introduction to Business Objects and Object Life Cycles

�Overview of Use Cases for Object Life Cycles

�Consistency of Business Process Models and Object Life Cycles

�Generation of a Business Process Model from Object Life Cycles

�Extraction of Object Life Cycles

�Resolution of Inconsistencies

�Summary and References




Business Process Models and Object Life Cycles




Business Objects

� A business object is a discrete entity that plays a role in business processes of an organization

� Examples: Claim, Bill, Contract

� Objects can be associated with a number of distinct business object states

� Modeling of business objects – UML class diagrams for capturing structure of business objects– UML state diagrams for capturing dynamics of business objects




UML State Diagrams for capturing Object Life Cycle

� Object life cycles model allowed state transitions

� No events/conditions/actions as in conventional UML State Diagrams

� Instead event is replaced by the activity which performs the transition on the object

registered

granted rejected

settledclosed

Object life cycle for Claim object type

register

settle

close

close

grant reject




Business Process Models and Business Object Flow

� Business process models capture coordination of activities performed to achieve a business goal

� Activities work on data, they consume data and produce new data

� In some occasions it is necessary to model data more explicitly

� Some process modeling languages support business objects– BPMN, UML 2.0

EvaluateClaim

MakePayment

NotifyRefusal

CloseClaim

X XReceiveClaim




Business Objects in BPMN

� BPMN supports the modeling of object flow

� Business objects define input and output of activities

� Business objects can be given states

� Decoupled and connected option

� Too much object flow introduces cluttering into the diagram

EvaluateClaim

ReceiveClaim

EvaluateClaim

ReceiveClaim

Claim Claim




Business Objects in UML 2.0

� UML 2.0 supports the modeling of object flow

� Explicit form of object flow:– Object flow connections– Object pins are used for outputting or reading a business object

� Implicit form of object flow (shorthand for this lecture):– Datastores are used– Connections between pins and datastores are omitted

EvaluateClaim

ReceiveClaim

EvaluateClaim

ReceiveClaim

<<datastore>>Claim

Claim




Business Process Models and Business Object Flow

� Object pins and data stores support the modeling of business object flow

� Decision conditions can be specified in terms of the state of business objects (see Data-based Routing Pattern)

EvaluateClaim

NotifyRefusal

<<datastore>>Claim

<<datastore>>Payment

MakePayment

CloseClaim

ReceiveClaim

granted

rejected




Overview of Use Cases for Object Life Cycles




Use Cases of Object Life Cycle Modeling (1)

1. Model both Business Process Models as well as Object Life Cycles– To get an overview of how business objects are manipulated– To complete the picture of the business process (another view)

2. Establish consistency between Business Process Models and Object Life Cycles– To improve the quality of the overall model– To ensure consistency with reference object life cycles




Use Cases of Object Life Cycle Modeling (2)

3. Generate a process model from existing object life cycles– To understand better the hidden process behind object life cycles– To follow a process-driven approach for implementation– To ensure consistency of object life cycles with generated process model

4. Extract object life cycles from business process models– To get an overview of how business objects are manipulated– To ensure consistency of process model with extracted life cycles– To follow an object-based approach for implementing processes




Techniques for Process Models and Object Life Cycles

� A consistency concept for the two views (for checking consistency)

� Model transformations for generation and extraction

� Resolution of inconsistencies by predefined transformations

PM

OLC

PM

OLC

PM

OLC

PM

OLC

PM’

OLC’

2a. checkconsistency

2b. resolveinconsistencies

4. extract object life cycles

3. generateprocess model




Consistency of Business Process Models and Object Life Cycles




Relationship between process models and object life cycles

� Process models and object life cycles represent overlapping behavior

registered

granted rejected

settledclosed

EvaluateClaim

NotifyRefusal

CloseClaim

ReceiveClaim

OfferBenefit


Process model for Claim Handling process

triggers one of

triggers

triggerstriggers

creates object / triggers initial transition




evaluateclaim

notifyrefusal

Process model for Claim Handling process

<<datastore>>Claim


[granted,rejected]

[granted]

[rejected,cancelled]


[granted,rejected]

[paid in full]

[granted,rejected,

cancelled] [closed]

[granted]

[rejected]

[registered]

[registered]

Creates Claim objects in state registered

Induces transitions from registered to granted and from

registered to rejected for Claim

objects

Does not induce transition from cancelled to

rejected for Claim objects

Creates Payment objects in state

paid in fullClaim can be in state closed or rejected

and Payment can be in state paid in full

makepayment

closeclaim

receiveclaim

Checking Consistency - Example

registered

granted rejected

settledclosed


register

settle

close

close

grant reject




� Conformance: all induced transitions, first states and last states in process model have corresponding elements in object life cycle

� Coverage: all transitions, target states of initial transitions and final states in object life cycle must have corresponding elements in process model

– transition– target of initial transition– final state

– induced transition– first state– last state

corresponding elements

evaluateclaim

notifyrefusal

[granted,rejected]

[granted]



[granted,rejected]

[paid in full]

[granted,rejected,

cancelled] [closed]

[granted]

[rejected]

[registered]

[registered]

makepayment

closeclaim

receiveclaim

Checking Consistency – Forms of Consistency

registered

granted rejected

settledclosed

register

settle

close

close

grant reject




registered

granted rejected

settledclosed

evaluateclaim

notifyrefusal

closeclaim

receiveclaim

offerbenefit

[granted,rejected]

[granted]



[granted,rejected]

[paid in full]

[granted,rejected,

cancelled] [closed]

[granted]

[rejected]

[registered]

[registered]

� Non-conformant transitions: (1) offer benefit task induces transition from state granted to rejected and (2) close claim task induces transition from state granted to state closed, which are not defined in the object life cycle

� Non-conformant last state: (3) rejected is a last state in the process model, but it is not a final state in the object life cycle

� Non-covered transitions: (4) transitions from state granted to settled and (5) from state settled to closed are not induced in the process model

Examples of possible inconsistencies




Approaches to achieving consistency

Authorized

Settled

PartiallySettled

Authorize

Settle in full

Pay

Pay

Requested Request

Authorized

Settled

PartiallySettled

Authorize

Settle in full

Pay

Pay

Requested Request

Authorized

Settled

PartiallySettled

Authorize

Settle in full

Pay

Pay

Requested Request

Object life cycles

Check forfraud

Registernew claim

Claim Claim

Claim[Possible fraud]Initiatefraud

investigation

Initiatefraud

investigation

[No fraud]

Existing business

process model

Check forfraud

Registernew claim

Claim Claim


investigation

Initiatefraud

investigation

[No fraud]

Consistencyensured

2. Resolutionof inconsistencies

1. Consistency checking

Authorized

Settled

PartiallySettled

Authorize

Settle in full

Pay

Pay

Requested Request

Authorized

Settled

PartiallySettled

Authorize

Settle in full

Pay

Pay

Requested Request

Authorized

Settled

PartiallySettled

Authorize

Settle in full

Pay

Pay

Requested Request

Object life cycles

Check forfraud

Registernew claim

Claim Claim


investigation

Initiatefraud

investigation

[No fraud]

Initial businessprocess model

Check forfraud

Registernew claim

Claim Claim


investigation

Initiatefraud

investigation

[No fraud]

Customized business

process model

!!!Inconsistencies

Check forfraud

Registernew claim

Claim Claim


investigation

Initiatefraud

investigation

[No fraud]

Consistency ensured

1. Process modelgeneration

2. Customization

3. Consistency Checking

4. Resolutionof inconsistencies

!!!Inconsistencies

! !!!!




Generation of a Business Process Model from Object Life Cycles




registered

granted rejected

settledclosed

register

settle

close

close

grant reject

1. For each event labeling a state transition in object life cycle, an activity is generated with appropriate input/output pins and object states

register

[registered]

grant

[registered] [granted] [registered]

reject

[rejected]

[granted] [settled]

settle close

[closed][settled,rejected]

Generation from one object life cycle




registered

granted rejected

settledclosed

register

settle

close

close

grant reject


2. Order of activities is based on matching input/output object states

reject

[registered]

[rejected]

grant

[registered] [granted]

settle

[granted] [settled]

register

[registered]

close






registered

granted rejected

settledclosed

register

settle

close

close

grant reject



3. Control nodes are added for correct control flow

reject

[registered]

[rejected]

grant


settle

[granted] [settled]

register

[registered]

close


<<datastore>>Claim





registered

granted rejected

settledclosed

register

settle

close

close

rejectgrantevaluate

reject

[registered]

[rejected]

grant


settle

[granted] [settled]

register

[registered]

close


<<datastore>>Claim




3. Control nodes are added for correct control flow

4. Combination of selected activities

evaluate closeregister

settle[granted,rejected]

[granted] [settled]

[settled,rejected] [closed]

[granted]

[rejected]

[registered]

[registered]

<<datastore>>Claim




Generation from a set of object life cycles

created

authorized

paid in full partially paid

pay all

pay all

authorize

stopped

pay installment

stop

stop

pay installment

create

registered

granted rejected

settledclosed

register

rejectgrant

closesettle

close

synchronization

registerC

(I1C,I2

P)

RGC,I2P

RJC,I2P

CLC,I2P

GRC,CRP

GRC,RFP

GRC,AUP

GRC,STP GRC,PPP

SEC,PFP CLC,PFP

rejectC

closeC

grantC |createP

refuseP

authorizeP

stopP

settleC |pay allP

settleC |pay allP

stopP

closeC

payinstallmentP

payinstallmentP

rejectC

closeC

refuseP

stopP

payinstallmentP

settleC |pay allP

C[RG]

C[RG]

C[RG]

C[RJ]

C[GR]

C[SE,RJ] C[CL]

P[CR]

P[CR] P[RF]

P[CR] P[AU] P[AU,PP]

P[AU,PP]

P[PP]

P[PF]P[AU,PP]

P[ST]

C[SE]

registerC

C[GR]

grantC | createP authorizeP

<<datastore>>C

<<datastore>>P

C[RG]

C[RG]

P[CR]

P[CR]

P[AU]

P[AU]

P[AU]

P[PP]

P[PP]

P[PP]

1. Identification of synchronization events (manual step)

2. Composition of object life cycles

3. Process model generation:– Task generation– Object state relation for tasks– Process fragment generation– Connection of process fragments




Identification of synchronization events

� A synchronization event is an event that triggers state transitions in more than one object life cycle

� Identifying synchronization events is necessary given several object life cycles, to ensure that invalid composite states cannot be reached

created

authorized

refused


create

pay all

pay all

authorize

refuse

stopped

pay installment

stop

stop

pay installment

I2

Object life cycle forPayment object type

registered

granted rejected

settledclosed


register

settle

close

close

grant reject

I1

grant C | create P

grant C | create P

settle C | pay all P

settle C |pay all P

settle C |pay all P




Composition of object life cycles

register C

(I1C,I2P)

registered C

I2P

rejected C

I2P

closed C

I2P

granted C

created P

granted C

refused P

granted C

authorized P

granted C

stopped P

granted C

partially paid P

settled C

paid in full Pclosed C

paid in full P

reject C

close C

grant C |create P

refuse P

authorize P

stop P

settle C |pay all P

settle C |pay all P

stop P

close C

payinstallment P

payinstallment P

registered

granted rejected

settledclosed

register

settle

close

close

grant reject

I1

grant C | create P

settle C | pay all P

created

authorized

refused


create

pay all

pay all

authorize

refuse

stopped

pay installment

stop

stop

pay installment

I2grant C | create P

settle C |pay all P

settle C |pay all P

closed C

refused P

closed C

stopped P




Process model generation

� Transition and first state conformance with respect to both object life cycles are satisfied, but last state conformance is not

� All coverage conditions are satisfied here, but this is not guaranteed

reject C

close C

refuse P

stop P

settle C |pay all P

register C

grant C | create P

authorize P

[partially paid]

[registered]

[registered]

[registered]

[rejected]

[granted]

[settled, rejected] [closed]

[created]

[created] [refused]

[created] [authorized][authorized,

partially paid]

[authorized,partially paid]

[partially paid]

[paid in full][authorized,partially paid]

[stopped]

[settled][granted][registered]

[registered]

[created]

[created]

[authorized]

[authorized]

[authorized]

[partially paid]

[partially paid]<<datastore>>Claim


payinstallment P




Extraction of Object Life Cycles




Example for Extraction of Life Cycles

Check forfraud

Evaluate

Initiatefraud

investigation

Preparesettlement

Notifyrejection

Prepare forreevaluation

Close

ClaimClaim

Claim

Claim

Claim

Claim[Granted]

[Settled]

[NotFraudulent]

[Granted]

[PreRejected]

[Rejected]

[Registered]

[NotFraudulent,NeedsReevaluation]

[Authorized] [Settled]

[Rejected,NeedsReevaluation]

Carry outpayment

[Settled,Rejected]

[Closed]

[NeedsReevaluation]

Claim[NeedsReevaluation]

Claim

xClaim

ClaimClaim

Claim

Settlement

Claim

Settlement

Claim

Claim

Claim

[Rejected]

Claim

Registernew claim

Settlement

[Requested]Settlement

[Requested]

Settlement

[Granted,Rejected,

PreRejected]

[Fraudulent,NotFraudulent]

[Fraudulent]




Transformation Rules for Generation

A

Rule 1 (objectCreation)

Process model P Object life cycle OLCP for O

O[s1,…,sn]

s1 sn…

A A

A

O[s11,…,s1m]

s11 s1m

s21 s2n

A AA A

Rule 2 (stateChange)O

[s21,…,s2n]…

…

s1

O[s1,…,sn]

Rule 5 (processInput)

sn…O

STARTP STARTP

Rule 4 (finalNode)

s1

O[s1,…,sn]

sn…x

…

O[s1,…,sn]

OR

Rule 3 (finalConsumption)

A

O[s1,…,sn]

s1 sn…A A

…

Rule 6 (processOutput)

s1 sn…

…ENDP

O[s1,…,sn] O ENDP




Check forfraud

Generating object life cycles from Claims handling process

Registered

Register new claim

Preparesettlement

ClaimClaim

Claim

Claim

[Fraudulent]

[NotFraudulent]

[Granted]

[Registered][Fraudulent,

NotFraudulent]


Carry outpayment

xClaim

Settlement

Claim

Settlement

Claim

Registernew claim

Settlement Settlement


Claim

[Registered]

Rule 1 (objectCreation)

[Requested]

Initiatefraud

investigation




Check forfraud


Registered

Register new claim

Fraudulent

Check for fraud

Initiatefraud

investigation

Preparesettlement

ClaimClaim

Claim

Claim

[Fraudulent]

[NotFraudulent]

[Granted]



Carry outpayment

xClaim

Settlement

Claim

Settlement

Claim

Registernew claim



Claim


Rule 2 (stateChange)

[Requested]

[Registered]

NotFraudulent

Checkfor fraud




Check forfraud


Registered

Register new claim

Fraudulent

Check for fraud

Initiatefraud

investigation

Preparesettlement

ClaimClaim

Claim

Claim

[Fraudulent]

[NotFraudulent]

[Granted]



Carry outpayment

xClaim

Settlement

Claim

Settlement

Claim

Registernew claim



Claim

[Requested]

[Registered]

NotFraudulent

Checkfor fraud

Rule 3 (finalConsumption)




Generated Object Lifecycles

Registered

Register new claim

Fraudulent NotFraudulent

Checkfor fraud

Check for fraud

Initiate fraudinvestigation

Requested

STARTP

Settlement

Claim

Granted PreRejected

Settled

Closed

Evaluate

Evaluate

Settle

CloseNeedsReevaluation

Rejected

Notifyrejection

NotifyrejectionEvaluate

Close

Evaluate

Evaluate Evaluate

Authorized

Settled

Carry out payment

Prepare settlement




Resolution of Inconsistencies




Non-conformant transitions:

� transition from “granted” to “needs review” (ncnf_tran(settle, granted, needs review))

� transition from “needs review” to “reviewed” (ncnf_tran(review, needs review, reviewed))

Non-covered transitions:

� transition from “rejected” to “closed” (ncov_tran(rejected, closed)

Examples of Inconsistencies

decide onclaim notify

rejection

preparesettlement

openclaim

closeclaim[under

evaluation][granted,rejected]

[granted]

[rejected]

[closed][settled]

review

[needs review] [reviewed]

settle

[needs review,settled]

[granted,reviewed][granted][granted]

under evaluation

granted

settled

registered

rejected

closed




Inconsistency Resolution Rules

� inconsistency resolutions may be captured as resolution rules

� here: inconsistency resolutions for non-conformant transition

� application of the resolution rule leads to resolution of the inconsistency

� but: resolutions may introduce new inconsistencies as side effects and resolve other inconsistencies as side effects

[s,sk,..,sl]

r1: remove sfrom

input states

[sm,..,sn]

[sm,..,sn][sk,..,sl]

a

a

[si,..,sj]

r2: remove sfrom

output states

[s,sm,..,sn]

[sm,..,sn]

a

a

[si,..,sj]

r3: remove action a

ax y

x y




Inconsistency Resolution Rules and Side Effects

[s,sk,..,sl]

r1: remove sfrom

input states

[sm,..,sn]

[sm,..,sn][sk,..,sl]

Potential side effect of resolution r1:

� introduction of a new non-covered transition (if the transition in the business process provided coverage for a transition in the object life cycle)

settle


[granted,reviewed]

settle


[reviewed]

ncnf_tran(settle,

granted, needs review):

a

a

Concrete side effect of resolution r1:

� ncov_tran(granted, settled)

� side effects can only be determined precisely for a given concrete model




Object Life Cycles and Business Process Models - Tools

� Object life cycles introduce a complementary view

� Consistency management with business process models is required

� Ideal solution: – Process Modeling Environment supports both views and offers support for

consistency management

� Suboptimal solution:– Models are created in different Modeling Environments, no consistency

management, unclear how they are related




Summary of Lecture and References

� Introduction to Object Life Cycles and their relationship to Process Models

� Consistency Checking of Process Model and Object Life Cycle

� Generation of Object Life Cycles from Process Models

� Generation of Process Model from a set of Object Life Cycles

Further Reading:

� J. M. Küster and K. Ryndina and H. Gall: “Generation of Business Process Models for Object Life Cycle Compliance”, Proceedings 5th International Conference on Business Process Management, LNCS 4714, Springer, pages 165-181, October 2007.

� J. M. Küster and K. Ryndina: “Improving Inconsistency Resolution with Side-effect Evaluation and Costs” In G. Engels, B. Opdyke, D. C. Schmidt, F. Weil (Eds.): Proceedings ACM/IEEE 10th International Conference on Model Driven Engineering Languages and Systems, LNCS 4735, Springer, pages 136-150, October 2007.

Documents

Business Objects and Object Life Cycles - Researcher - IBM