Business Objects and Object Life Cycles - Researcher - IBM
Transcript of 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
IBM Research – ZurichProcess Management Technologies
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
© 2013 IBM Corporation3
IBM Research – ZurichProcess Management Technologies
Dr. Jochen Küster | BDSE 2013
Business Process Models and Object Life Cycles
© 2013 IBM Corporation4
IBM Research – ZurichProcess Management Technologies
Dr. Jochen Küster | BDSE 2013
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
© 2013 IBM Corporation5
IBM Research – ZurichProcess Management Technologies
Dr. Jochen Küster | BDSE 2013
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
© 2013 IBM Corporation6
IBM Research – ZurichProcess Management Technologies
Dr. Jochen Küster | BDSE 2013
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
© 2013 IBM Corporation7
IBM Research – ZurichProcess Management Technologies
Dr. Jochen Küster | BDSE 2013
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
© 2013 IBM Corporation8
IBM Research – ZurichProcess Management Technologies
Dr. Jochen Küster | BDSE 2013
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
© 2013 IBM Corporation9
IBM Research – ZurichProcess Management Technologies
Dr. Jochen Küster | BDSE 2013
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
© 2013 IBM Corporation10
IBM Research – ZurichProcess Management Technologies
Dr. Jochen Küster | BDSE 2013
Overview of Use Cases for Object Life Cycles
© 2013 IBM Corporation11
IBM Research – ZurichProcess Management Technologies
Dr. Jochen Küster | BDSE 2013
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
© 2013 IBM Corporation12
IBM Research – ZurichProcess Management Technologies
Dr. Jochen Küster | BDSE 2013
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
© 2013 IBM Corporation13
IBM Research – ZurichProcess Management Technologies
Dr. Jochen Küster | BDSE 2013
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
© 2013 IBM Corporation14
IBM Research – ZurichProcess Management Technologies
Dr. Jochen Küster | BDSE 2013
Consistency of Business Process Models and Object Life Cycles
© 2013 IBM Corporation15
IBM Research – ZurichProcess Management Technologies
Dr. Jochen Küster | BDSE 2013
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
Object life cycle for Claim object type
Process model for Claim Handling process
triggers one of
triggers
triggerstriggers
creates object / triggers initial transition
© 2013 IBM Corporation16
IBM Research – ZurichProcess Management Technologies
Dr. Jochen Küster | BDSE 2013
evaluateclaim
notifyrefusal
Process model for Claim Handling process
<<datastore>>Claim
<<datastore>>Payment
[granted,rejected]
[granted]
[rejected,cancelled]
[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
Object life cycle for Claim object type
register
settle
close
close
grant reject
© 2013 IBM Corporation17
IBM Research – ZurichProcess Management Technologies
Dr. Jochen Küster | BDSE 2013
� 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]
[rejected,cancelled]
[rejected,cancelled]
[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
© 2013 IBM Corporation18
IBM Research – ZurichProcess Management Technologies
Dr. Jochen Küster | BDSE 2013
registered
granted rejected
settledclosed
evaluateclaim
notifyrefusal
closeclaim
receiveclaim
offerbenefit
[granted,rejected]
[granted]
[rejected,cancelled]
[rejected,cancelled]
[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
© 2013 IBM Corporation19
IBM Research – ZurichProcess Management Technologies
Dr. Jochen Küster | BDSE 2013
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
Claim[Possible fraud]Initiatefraud
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
Claim[Possible fraud]Initiatefraud
investigation
Initiatefraud
investigation
[No fraud]
Initial businessprocess model
Check forfraud
Registernew claim
Claim Claim
Claim[Possible fraud]Initiatefraud
investigation
Initiatefraud
investigation
[No fraud]
Customized business
process model
!!!Inconsistencies
Check forfraud
Registernew claim
Claim Claim
Claim[Possible fraud]Initiatefraud
investigation
Initiatefraud
investigation
[No fraud]
Consistency ensured
1. Process modelgeneration
2. Customization
3. Consistency Checking
4. Resolutionof inconsistencies
!!!Inconsistencies
! !!!!
© 2013 IBM Corporation20
IBM Research – ZurichProcess Management Technologies
Dr. Jochen Küster | BDSE 2013
Generation of a Business Process Model from Object Life Cycles
© 2013 IBM Corporation21
IBM Research – ZurichProcess Management Technologies
Dr. Jochen Küster | BDSE 2013
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
© 2013 IBM Corporation22
IBM Research – ZurichProcess Management Technologies
Dr. Jochen Küster | BDSE 2013
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
2. Order of activities is based on matching input/output object states
reject
[registered]
[rejected]
grant
[registered] [granted]
settle
[granted] [settled]
register
[registered]
close
[closed][settled,rejected]
Generation from one object life cycle
© 2013 IBM Corporation23
IBM Research – ZurichProcess Management Technologies
Dr. Jochen Küster | BDSE 2013
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
2. Order of activities is based on matching input/output object states
3. Control nodes are added for correct control flow
reject
[registered]
[rejected]
grant
[registered] [granted]
settle
[granted] [settled]
register
[registered]
close
[closed][settled,rejected]
<<datastore>>Claim
Generation from one object life cycle
© 2013 IBM Corporation24
IBM Research – ZurichProcess Management Technologies
Dr. Jochen Küster | BDSE 2013
registered
granted rejected
settledclosed
register
settle
close
close
rejectgrantevaluate
reject
[registered]
[rejected]
grant
[registered] [granted]
settle
[granted] [settled]
register
[registered]
close
[closed][settled,rejected]
<<datastore>>Claim
Generation from one object life cycle
1. For each event labeling a state transition in object life cycle, an activity is generated with appropriate input/output pins and object states
2. Order of activities is based on matching input/output object states
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
© 2013 IBM Corporation25
IBM Research – ZurichProcess Management Technologies
Dr. Jochen Küster | BDSE 2013
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
© 2013 IBM Corporation26
IBM Research – ZurichProcess Management Technologies
Dr. Jochen Küster | BDSE 2013
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
paid in full partially paid
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
Object life cycle for Claim object type
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
© 2013 IBM Corporation27
IBM Research – ZurichProcess Management Technologies
Dr. Jochen Küster | BDSE 2013
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
paid in full partially paid
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
© 2013 IBM Corporation28
IBM Research – ZurichProcess Management Technologies
Dr. Jochen Küster | BDSE 2013
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
<<datastore>>Payment
payinstallment P
© 2013 IBM Corporation29
IBM Research – ZurichProcess Management Technologies
Dr. Jochen Küster | BDSE 2013
Extraction of Object Life Cycles
© 2013 IBM Corporation30
IBM Research – ZurichProcess Management Technologies
Dr. Jochen Küster | BDSE 2013
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]
© 2013 IBM Corporation31
IBM Research – ZurichProcess Management Technologies
Dr. Jochen Küster | BDSE 2013
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
© 2013 IBM Corporation32
IBM Research – ZurichProcess Management Technologies
Dr. Jochen Küster | BDSE 2013
Check forfraud
Generating object life cycles from Claims handling process
Registered
Register new claim
Preparesettlement
ClaimClaim
Claim
Claim
[Fraudulent]
[NotFraudulent]
[Granted]
[Registered][Fraudulent,
NotFraudulent]
[Authorized] [Settled]
Carry outpayment
xClaim
Settlement
Claim
Settlement
Claim
Registernew claim
Settlement Settlement
[Requested]Settlement
Claim
[Registered]
Rule 1 (objectCreation)
[Requested]
Initiatefraud
investigation
© 2013 IBM Corporation33
IBM Research – ZurichProcess Management Technologies
Dr. Jochen Küster | BDSE 2013
Check forfraud
Generating object life cycles from Claims handling process
Registered
Register new claim
Fraudulent
Check for fraud
Initiatefraud
investigation
Preparesettlement
ClaimClaim
Claim
Claim
[Fraudulent]
[NotFraudulent]
[Granted]
[Fraudulent,NotFraudulent]
[Authorized] [Settled]
Carry outpayment
xClaim
Settlement
Claim
Settlement
Claim
Registernew claim
Settlement Settlement
[Requested]Settlement
Claim
[Fraudulent,NotFraudulent]
Rule 2 (stateChange)
[Requested]
[Registered]
NotFraudulent
Checkfor fraud
© 2013 IBM Corporation34
IBM Research – ZurichProcess Management Technologies
Dr. Jochen Küster | BDSE 2013
Check forfraud
Generating object life cycles from Claims handling process
Registered
Register new claim
Fraudulent
Check for fraud
Initiatefraud
investigation
Preparesettlement
ClaimClaim
Claim
Claim
[Fraudulent]
[NotFraudulent]
[Granted]
[Fraudulent,NotFraudulent]
[Authorized] [Settled]
Carry outpayment
xClaim
Settlement
Claim
Settlement
Claim
Registernew claim
Settlement Settlement
[Requested]Settlement
Claim
[Requested]
[Registered]
NotFraudulent
Checkfor fraud
Rule 3 (finalConsumption)
© 2013 IBM Corporation35
IBM Research – ZurichProcess Management Technologies
Dr. Jochen Küster | BDSE 2013
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
© 2013 IBM Corporation36
IBM Research – ZurichProcess Management Technologies
Dr. Jochen Küster | BDSE 2013
Resolution of Inconsistencies
© 2013 IBM Corporation37
IBM Research – ZurichProcess Management Technologies
Dr. Jochen Küster | BDSE 2013
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
© 2013 IBM Corporation38
IBM Research – ZurichProcess Management Technologies
Dr. Jochen Küster | BDSE 2013
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
© 2013 IBM Corporation39
IBM Research – ZurichProcess Management Technologies
Dr. Jochen Küster | BDSE 2013
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
[needs review,settled]
[granted,reviewed]
settle
[needs review,settled]
[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
© 2013 IBM Corporation40
IBM Research – ZurichProcess Management Technologies
Dr. Jochen Küster | BDSE 2013
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
© 2013 IBM Corporation41
IBM Research – ZurichProcess Management Technologies
Dr. Jochen Küster | BDSE 2013
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.