A Case Modelling Language for Process Variant Management in Case-based Reasoning

Andreas Martin - FHNW

A Case Modelling Language for Process Variant Management in

Case-based Reasoning Riccardo Cognini 2, Knut Hinkelmann 1 and Andreas Martin 1

AdaptiveCM 2015 – 31.08.2015

4th International Workshop on Adaptive Case Management and other non-workflow approaches to BPM

1 FHNW University of Applied Sciences and Arts Northwestern Switzerland,

School of Business, Olten, Switzerland

2 University of Camerino, School of Science and Technology, Computer Science Department, Camerino, Italy

A Case Modelling Language for Process Variant Management in Case-based Reasoning

1


Introduction Problem / Research objective


2


Problem

Knowledge work is not routine work …

“[...] the sequence of actions depends so much upon the specifics of the situation [...] necessitating that part of doing the work is to make the plan itself" (Swenson, Palmer and Silver, 2011, p.8).

Difficult to predict upcoming tasks.

Hard to determine the type and scope of tasks.

Sequence of tasks may vary due to already achieved results and unforeseeable events.


3


Problem

Situation: As the term knowledge work implies, knowledge worker need experience and (procedural) knowledge to find a solution (approach, plan, activities) to specific situation / problem.

Underlying assumption: For knowledge work it seems useful to take approaches that structure business processes just in part as process fragments.

“Process fragments are reflecting the partial and intermittent knowledge one modeller [or a knowledge worker] has at a certain time about a specific situation" (Eberle,

Unger and Leymann, 2009, p.399).


4


Research objective

Knowledge workers are required to make decisions based on process fragments, which can only be made by the knowledge workers themselves at run-time.

Research objective: Therefore, a vocabulary and content representation (modelling language) is needed that support the manual planning, modelling, generation and refinement of process fragments during run-time.

Underlying method: We use case-based reasoning (CBR), to put the experience management into the hands of the knowledge worker and provide a way to retrieve and reuse historic process fragments.


5


What is Case-based Reasoning (CBR)?

CBR can be seen as “reasoning by remembering”…

and it is a technically independent methodology to humans and information systems.

“Case-based reasoning is both […] the ways people use cases to solve problems and the ways we can make machines use them”.

CBR has been applied in business process contexts, e.g., for workflow retrieval, adaptation, construction and monitoring.


6


What is Case-based Reasoning (CBR)?

CBR- CYCLE (& CASE- BASE)

Retrieve the most similar cases from the case-base containing previous cases, based on the problem description of the new case using a similarity mechanism.

Reuse the knowledge in the retrieved case(s) in order to solve the current problem – adapt the historical knowledge to the new problem (adaptation).

Revise and test the suggested solution e.g. by evaluating it under the real world situation (evaluation).

Retain useful experience for future reuse and store a new case in the knowledge base (case learning).


7

Based on: A. Aamodt and E. Plaza, “Case-Based Reasoning : Foundational Issues , Methodological Variations , and System Approaches,” Artificial Intelligence Communications, vol. 7, no. 1, pp. 39–59, 1994.


Application Scenario


8


Master Study Admission Process


9


(Sub-) Tasks based working Used for data collection

The end user are familiar with an task / task pattern concept.

The data used in this approach was initially gathered in an EU project called MATURE:


10


CASE CASE

Demanding*) example

1. In the first case the problem is solved by calling the university of the applicant student asking for some information.

2. In the second case the university is called and then proof of the existence of the university.

3. In the last case just the proof of the of existence of the university is requested.

*) These three examples are not the demanding “thing”, it is the fact that an uncountable and unknown variation of these process fragments can exist.


11

CASE


Application Scenario Analysis

Application Scenario Analysis: Knowledge workers (as shown in application scenario) currently working with concrete process fragments / (sub-) tasks.

As improvement: Case generalization and abstraction can reduce the complexity of the cases, increase the flexibility and reduce the size of the case base to enhance the retrieval efficiency.

Therefore we introduce a case-based process fragment modelling language that supports the manual generation and refinement of generalized cases in CBR based approach.


12


Approach Comparison


13


Drawbacks of: BPMN and other Imperative Languages

End users …

do not have enough time, knowledge and skills to model or update a BPMN model.

are able to specify which activities should be performed and by whom,

but they are not able to establish a temporal order,

because they are focused just on their own tasks.

Imperative languages …

are designed to express something that is fully defined including all the possible aspects.

“is like modifying” a software source code written by someone else.


14


CMMN, a declarative language

is a designed to model non predefined, partially structured and non repeatable business processes.

Mandatory and optional activities can be modelled without

specifying an execution order or

the situation in which an activity can be executed.

Issue of CMMN …

it is not possible to specify complex execution criteria.

E.g. it is not possible to specify at least one of the activities in a set has to be executed.

complex data elements are not provided;

it implies that just little information about the type of data or document is available.


15


Comparison of Modelling Languages

We propose the use of BPFM notation as a language for case representation in CBR. BPFM: permits defining the BP activities that must or can be performed with

and without including an execution order

considers complex constraints and different types of data objects.

is a configurable process model since it can encapsulate more than one BP variant


16


The Approach… …Business Process Feature Model Notation


17


Business Process Feature Model (BPFM) The Business Process Feature

Model is constituted by a tree of related activities.

The root identifies the main services.

Each internal (non-leaf) activity denotes a sub-process that can be further refined.

The external (leaf) activity represents an atomic task.

BPFM allows using the same meaning and graphical representation given by BPMN 2.0.

A BPFM model allows for the defining constraints between activities.


18


Mapping BPFM Activities to BPMN


19


Constraints in Business Process Feature Model (BPFM)

Constraints are used to express

if child activities can or have to be selected in the configuration to be included in the BP variant, and

if they can or have to be included in each execution path of the BP variant.


20


Mandatory Constraints


21

Mandatory Constraint requires that the connected child activity must be inserted in each BP variant,

and it must be included in each execution path.


Special Case Constraints


24

A Special Case Constraint allows for the connected child activity to be inserted in each BP variant.

When it is inserted it must be included in each execution path.


Inclusive Constraints


25

An Inclusive Constraint requires that at least one of the connected child activities be inserted in each BP variant,

and at least one of them must be included in each execution path.


One Selection Constraints


27

A One Selection Constraint requires that exactly one of the connected child activities be inserted in each BP variant,

and it must be included in each execution path.


Data Objects in BPFM


30

BPFM manages all types of BPMN 2.0 data objects, including data object states, with the same modelling notation


Data Mapping to BPMN


31


User Acceptance?


32


User Acceptance?


33


User Acceptance?


34


The Approach… …BPFM in Case-based Reasoning (CBR)


35


Back to Case-based Reasoning (CBR)

THE CASE

Traditional CBR terminology: a case consists of a problem space that is used for describing a certain solution space.

Our CBR terminology: a case consists of a case characterization (derived from

Bergmann) that is used for describing a certain case content.


36

Characterization

Content

CASE


Retrieval

De

scriptio

n

Case-based Reasoning Cycle - Retrieval


38

Retrieve

CASE BASE

NEW Situation

How is: the configuration (model) and the retrieval

realized ?


ArchiMEO is an enterprise ontology based on ArchiMate and is extended with selected concepts from other enterprise ontologies.

ArchiMEO is implemented using RDF(s) and OWL.

ArchiMEO has been developed by several team members of the FHNW Information and Knowledge Management Research Group (IKM).

ArchiMEO is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.

ArchiMEO is available for download as TTL- files (Terse RDF Triple Language) under: ikm-group.ch/archimeo


39

ArchiMate is a technical standard from The Open Group.

RDF(S) / OWL is a W3C standard.

The enterprise ontology ArchiMEO is based on ArchiMate.


Ontology-based Case-based Reasoning (OBCBR)


40


Case Characterization describing Process Knowledge


41

Further elements:

TaskObjective: The task objective element describes the goal of the task itself. This is similar to the name and/or description of an BPMN activity.

TaskRole: The task role element is used to describe the role of the involved person of the task. Through the inclusion of an enterprise or domain ontology, it is possible to reuse an existing enterprise specific role / organizational model.

TaskUser: The task user elements is used to indicate the person who described the case.


Demonstration


42


Learn

ing

Retrieval

Ad

aptatio

n

De

scriptio

n

Extended Case-based Reasoning Cycle


43

Reuse

Retrieve

CASE BASE

Retain Revise / Generalize

Revise

NEW Situation

Evaluatio

n


Concrete CASEs


44

Characterization

Content

CASE A

Characterization

Content

CASE B


Generalized CASE


45

Characterization

Content

Generalized CASE


Implementation


46

ICEBERG Toolkit

BPFM Modelling Platform


Interlinked Case-based Reasoning (ICEBERG)


47

ICEBERG Approach & Toolkit: Using interlinked (ontology-based) case-based reasoning to bring hidden knowledge to the surface.


ICEBERG - System architecture

Technology:

Apache Jena: open source Java framework for building Semantic Web applications

OpenDolphin: open-source library for a lightweight remote model-view-controller separation.

JavaFX: GUI framework

TopBraid Composer: an ontology engineering software (paid)


48


Adapting case models / content BPFM Modelling Platform an OMiLAB Project


49


Conclusion and Future Work


50


Conclusion and Future Work

This paper presented an approach to model cases in knowledge-intensive BPs.

The approach merges CBR with BPFM notation in order to represent cases.

We applied the approach to a concrete case in a public administration scenario in order to show its suitability.

Future Work: We plan to …

… make further evaluation with the respect to usability of different modelling languages / elements.

… transfer the approach to a different scenario.

A Case Modelling Language for Process Variant Management in Case-based

Reasoning 51

A Case Modelling Language for Process Variant Management in Case-based Reasoning

Science

Transcript of A Case Modelling Language for Process Variant Management in Case-based Reasoning