Overcoming Heterogeneity in Business Process Modeling with Rule-Based Semantic Mappings

Abstract

The paper tackles the problem of notational heterogeneity in business process modeling. Heterogeneity is overcome with an approach that induces semantic homogeneity independent of notation, driven by commonalities and recurring semantics in various control flow-oriented modeling languages, with the goal of enabling process simulation on a generic level. Thus, hybrid process models (for end-to-end or decomposed processes) having different parts or subprocesses modeled with different languages become simulate-able, making it possible to derive quantitative measures (lead time, costs, or resource capacity) across notational heterogeneity. The result also contributes to a better understanding of the process structure, as it helps with identifying interface problems and process execution requirements, and can support a multitude of areas that benefit from step by step process simulation (e.g. process-oriented requirement analysis, user interface design, generation of business-related test cases, compilation of handbooks and training material derived from processes). A use case is presented in the context of the ComVantage EU research project, where notational heterogeneity is induced by: (a) the specificity and hybrid character of a process-centric modeling method designed for the project application domain, and (b) the collaborative nature of the modeling effort, with different modelers working with different notations for different layers of abstraction in a shared on-line tool and model repository.

Dynamical Aspects of Knowledge Evolution

“…employees, faculties); • cardinality changes: in particular, cardinality relationships between domains might also change over time; in other words, the number of occurrences in one entity which are associated to the number of occurrences in another are not always constant; for example, a 1-to-n relationship between departments and faculties may be changed to m-to-n as a result of new legal regulations; • granularity transition: from existing population values, having different granularity, might be added to a domain extension; for instance, the numeration of rooms or buildings might be changed due to the merge or acquisition [84,85]; • encoding changes: particular values might have also encoded meaning, which neither is known, nor provided elsewhere; for example, the naming of projects successfully delivered are eventually different from the others (failed, cancelled, etc. ; see [86]); • time zone and unit differences: organization sites use local time zone and units which globally differ; thus directly comparing such values may be irrelevant; • identifier changes: the organization needs changes over time; as a consequence the indexing strategies may also change over time, leading in parallel or overlapping naming schemas; for instance, the codes of the products, previously 4-digits numbers, now having additional 6 zeros, are different for both the users and IT systems; • field recycling: in some systems it is difficult or even infeasible to alter certain database properties; in this case there might be a need to shrink the database or even implement a new instance with a different naming schema, replacing the existing ones; for example, a company might shift from hierarchical to a matrix structures, remodeling data structures [87,88,89].…”