Incremental inconsistency detection with low memory overhead

Abstract

Ensuring models' consistency is a key concern when using a model-based development approach. Therefore, model inconsistency detection has received significant attention over the last years. To be useful, inconsistency detection has to be sound, efficient, and scalable. Incremental detection is one way to achieve efficiency in the presence of large models. In most of the existing approaches, incrementalization is carried out at the expense of the memory consumption that becomes proportional to the model size and the number of consistency rules. In this paper, we propose a new incremental inconsistency detection approach that only consumes a small and model size-independent amount of memory. It will therefore scale better to projects using large models and many consistency rules.Many approaches dealing with inconsistency management exist in the literature. The first generation of approaches that tackle this challenge uses inconsistency rules and executes them on models in batch [9][10][11][12][13][14]. The limitation of these first generation approaches, also called batch checkers, is efficiency. The main problem is that each time a model is modified, all inconsistency rules have to be rechecked as a whole, which turns to be highly time consuming. As reported by [3], checking large models with batch checkers can then take hours to complete, which cannot be sustainable in effective development processes.A second generation of approaches has then emerged to deal with efficiency. These approaches, also called incremental checkers, limit the set of rules to recheck (rule reduction) and/or the model elements to consider (scope reduction) after each model change [15][16][17][18]. The most efficient approaches intensively use cache memory, thus introducing a memory overhead relative to the size of models and requiring a mechanism to manage the cache along the model's life cycle. An experimental study shows that one of the current fastest incremental checkers has a cache that induces a linear memory overhead on several real-world Unified Modeling Language (UML) models but that has a worst-case memory overhead that is quadratic in the number of elements [15]. With the increasing complexity and size of industrial design models, we believe that optimal memory management (scalability) in inconsistency management is as important as response time (efficiency). This is also confirmed by our industrial partners, which have realized a case study that confirms the critical need for more optimal memory management for large and complex models [19].In this paper, we present an incremental checker that puts more emphasis on scalability rather than on efficiency. It has no cache and requires only a fixed memory overhead to perform both rule and scope reductions. Even if it cannot perform reduction for some cases (explained in Section 5) and is therefore less efficient than checkers that use cache for such cases, the intensive benchmark we have performed, using real large open source models, shows that it is fast enough (rechecks are perf...

Automatic Business Process Model Extension to Repair Constraint Violations

“…In the conceptual modeling literature, there are quite a lot of proposals for incrementally evaluating constraints [3,12,26]. Using these techniques, it is possible to eciently identify when the execution of some activity leads to a constraint violation.…”

Incremental Checking of OCL Constraints with Aggregates Through SQL

“…Thus, when any of these relevant data is modified, the corresponding OCL constraint is reevaluated for such context element. However, this strategy might be prohibitive due to excessive memory usage depending on the kind of constraints involved [21]. Instead of storing all these data, the works of [5] and [7] are able to compute, given a data update, the constraints that might be violated together the context element for which they should be reevaluated.…”

Computing repairs for constraint violations in UML/OCL conceptual schemas

“…The work in [3] specifies the constraints in Prolog, and checks them using the updates of the elements that occur in the data. Proposals like [4,5,6] directly work with OCL interpreters from which they assess which OCL constraints should be checked and for which values.…”

“…To avoid so, several techniques have been proposed to efficiently check constraint satisfaction [2,3,4,5,6]. Using these techniques, it is possible to detect those violations committed by the events, but none of them is able to propose additional changes, i.e., repairs, that would bring the IB back to a consistent state where all constraints are satisfied.…”