Home

This wiki provides an overview of the general characteristics of fragment-based Case Management (fCM) and lists concrete guidelines that support and simplify modeling with this approach. For a given business process, this allows designers to first check whether fCM is a suitable modeling language for the process. If this is the case, the guidelines provide assistance for modeling in the form of suggestions. Furthermore, they can be used as a basis for a modeling tool and can be checked automatically. The guidelines thus summarize what constitutes a correct fCM model.

Guidelines' Structure

The guidelines were developed in order to support designers who are already familiar with the domain of business process modeling but lack knowledge/understanding of fCM. Users without any previous experience with modeling or business processes will only be able to use these guidelines to a limited extent. Based on the general structure of fCM, the Guidelines are grouped by Guidelines for Fragments, Objects Lifecylce (OLC), Data Model, Goal State, and Consistency Checking. The first four categories represent the four artifacts of fCM and the fifth category represents suggestions for cross-artifact modeling, i.e., dependencies between, for example, OLC and the fragments. This grouping supports the designer in every way of modeling. It does not matter whether modeling is based on a fragments-first approach or whether the OLC is in the foreground first. This preserves the flexibility of the user.

In general, a guideline consists of three required components (ID, Name and Description) and three optional components (Example, Motivation and References). This framework is based on the work of Corradini et al. who presented modeling guidelines for BPMN. The closeness of fCM to BPMN motivated to adopt some suggestions and extend the framework in other parts.

• ID: A combination of a letter (first letter of the artifact) and a number uniquely identifies a guideline. For example, "F1" for the first Guideline for Fragments. This is only for easier assignment.
• Name: A short, concise name for the guideline that briefly tells the designer what it contains.
• Description: This explanation describes the guideline and its content in more detail.
• Example: A bad example and an improved version of it are used to visualize the content of the guideline and make it easier to understand. The examples are all based on the Use Case XYZ. However, it is not always possible to provide an example, so this component is optional.
• Motivation: Some guidelines cannot be derived directly from fCM, because the modeling approach often allows several ways to model a situation. However, based on the context and content of the process, one option should be preferred. The rationale for this is provided in this component.
• References: A list of literature for further information. This includes sources that have led to the formulation and reason for existence of the Guideline.

References

Corradini, F., Ferrari, A., Fornari, F., Gnesi, S., Polini, A., Re, B., & Spagnolo, G. O. (2018). A guidelines framework for understandable BPMN models. Data & Knowledge Engineering, 113, 129-154.