Variability in Artifact-Centric BPM The Hetero-Homogeneous Approach Christoph Schütz, Michael Schrefl
Overview Introduction Multilevel Business Process (Model) Variability in the Large: Hierarchies of Process Models Variability in the Small: Hierarchies within Levels Related Work Summary and Future Work 2
Introduction Artifact-Centric Process Modeling Focus on the business objects (artifacts) Data model Life cycle model Process Variability Different business situations demand different variants of the same process model Rigidity vs. flexibility 3
Multilevel Business Process Companies are (predominantly) hierarchical organizations Different hierarchical levels l have different processes These processes are interdependent 4
Multilevel Business Process Model Multilevel Business Artifact (MBA) Artifact-centric modeling of multilevel business processes Data and life cycle models Class/object duality 5
Multilevel Business Artifact (MBA) An MBA has several abstraction ti levels l 6
Multilevel Business Artifact (MBA) Each level has a class These classes are in an aggregation relationship Multilevel Object (Neumayr 2009) 7
Multilevel Business Artifact (MBA) 8
Multilevel Business Artifact (MBA) An MBA instantiates the class of its single top levell 9
Multilevel Business Artifact (MBA) 10
Multilevel Business Artifact (MBA) Each class has methods which h change the data 11
Multilevel Business Artifact (MBA) Some methods may only be called in a pre-defined d order or when the object is in a particular state. 12
Multilevel Business Artifact (MBA) The life cycle models of the different levels l are interdependent Pre- and postconditions link the different levels Multilevel predicates as syntax macros for OCL 13
Multilevel Business Artifact (MBA) post: alldescendantsat- LevelInState(l t 2,s) 14
Multilevel Business Artifact (MBA) post: alldescendantsat- LevelInState t (<rentertype>, Phase Out) 15
Multilevel Business Artifact (MBA) post: self.descendants (<rentertype>)->forall( o o.oclinstate(phase Out) ) 16
Multilevel Business Artifact (MBA) pre: ancestoratlevel- InState(l t 1,s) 17
Multilevel Business Artifact (MBA) pre: ancestoratlevel- InState t (<business>, In Business) 18
Multilevel Business Artifact (MBA) pre: self.ancestor(<business>).oclinstate(in Business) 19
Multilevel Business Artifact (MBA) post: newdescendantat- LevelSatisfies(l 2,a 1,val,=) 20
Multilevel Business Artifact (MBA) post: newdescendantat- LevelSatisfies (<rental>, rentalid, id, =) 21
Multilevel Business Artifact (MBA) post: self.descendants(<rental>) d t l ->exists( o o.oclisnew() and o.rentalid = id) 22
Hierarchies of Multilevel Process Models VARIABILITY IN THE LARGE 23
Multilevel Concretization Incremental evolution of multilevel processes using concretization An MBA may be the concretization of another MBA The concretization may specialize classes, extend and refine the life cycle models, and introduce new abstraction levels The concretization represents a sub-hierarchy 24
Multilevel Concretization Multilevel concretization determines the membership to an aggregate A concretization is defined at a more specific level 25
Multilevel Concretization The classes defined by a concretization are specializations Observation-consistent specialization (Schrefl & Stumptner 2002) 26
Multilevel Concretization Pre- and postconditions must be at least as strong as in the more general model 27
Hierarchies of Process Models within Levels VARIABILITY IN THE SMALL 28
Specialization Hierarchy within Levels Rental: business rentertype rental + rentalid : String + actualpickup : Date + rentalduration : Number + rate : Number + assignedcar : String Rental Opening setduration setrate pickup assigncar Open return Closed + scheduledpickup : Date AdvanceRental setduration Opening setrate Booking book setscheduledpickup Booked assigncar Assigned pickup Open return Closed 29
Incremental Evolution Private: rentertype rental Rental: business PrivateRental rentertype + creditcard : Number Opening rental setduration setrate assigncar pickup Open + rentalid : String + actualpickup : Date + rentalduration : Number + rate : Number + assignedcar : String Opening setduration setrate pickup assigncar Rental Open return Closed Unbacked setcreditcard Backed PrivateAdvanceRental + deposit : Number Opening setduration setrate return Closed Booking book Booked + scheduledpickup : Date AdvanceRental setscheduledpickup assigncar Assigned setduration Opening setrate Unbacked pickup Open return Booking setcreditcard setscheduledpickup Backed book Authorized deposit Guaranteed Booked assigncar Assigned pickup Open return Closed Closed 30
Related Work Powertypes Deep Instantiation Materialization Object-Process Methodology (Dori, 2002) 31
Related Work Powertypes Deep Instantiation Materialization Object-Process Methodology (Dori, 2002) 32
Related Work Powertypes Partitioned Type + Powertype A level of an MBA may act both as partitioned type and powertype In an MBA s level l hierarchy, h a parent level l is the powertype of the child level 33
Related Work Object-Process Methodology Function boxes RentalBusiness Restructure Run Business RenterType Launch Manage renter type Set maximum duration Rental Set duration Handle rental Assign car Set rate 34
Summary and Future Work Tradeoff between rigidity of hierarchical organization and flexibility Homogeneous model, interspersed with heterogeneities in well-defined sub-hierarchies Future work: Integration of hetero-homogeneous approach into existing modeling languages and tools (e.g., guard-stage-milestone) Business process intelligence and MBAs (Hetero-Homogeneous Process Warehouse) 35
References Dori, D. (2002): Object-Process Methodology: A holistic systems paradigm. Springer, Heidelberg. Neumayr, B.; Grün, K.; Schrefl, M. (2009): Multilevel domain modeling with m-objects and m-relationships. Proceedings of APCCM 2009, pp. 107-116. Nigam, A. & Caswell, N. S. (2003): Business artifacts: An approach to operational specification. IBM Systems Journal 42(3), 428 445. Schrefl, M. & Stumptner, M. (2002): Behavior-consistent specialization of object life cycles. ACM Transactions on Software Engineering and Methodology 11(1), pp. 92-148. 36