Set Of Model Elements Research Articles

Determining the Cause of Design Model Inconsistencies

D on’t you just hate it when you find an error in your design and then have to work out where it came from? What caused it? Is it a minor modeling error? Or more fundamentally, does it result from an inconsistent design or even a requirements error? These issues have bedeviled designers and programmers alike since the days of the ENIAC. With today’s increasingly complex designs and composite systems, identifying and correcting design errors early and accurately is more critical than ever. In a recent article in IEEE Transactions on Software Engineering (vol. 39, no. 11, 2013, pp. 1531–1548), Alexander Reder and Alexander Egyed from Johannes Kepler University, Linz, Austria, bravely tackle this problem. They’ve produced a major advance in inconsistency analysis— moving beyond just identifying a design inconsistency to accurately showing designers where the inconsistency originates. Their work starts from the premise that visualizing an inconsistency in a design tool ought to also involve visualizing its cause, a novel concept not previously explored in software engineering design. Understanding the cause is vital in formulating a suitable repair, whether manual or automated. And to understand the cause, it must be understood that behind an inconsistency is a design rule—a constraint—that the design violated. Inconsistency is defined in how the various parts of the design rule contributed to the inconsistency and identifying which model element in the design influenced those parts. To do so, the authors present an equally novel approach for computing the cause of design model inconsistencies by looking at inconsistencies from two angles: the syntactic structure of design rules to understand the expected results of their parts and the validation results to determine where the validated results match the expected results. The cause of an inconsistency is then the set of model elements that contributed to validations that didn’t match expectation. The authors rigorously evaluate this novel technique and supporting prototype tool plug-in using a correctness measure (based on causes being complete and minimal), an effectiveness measure (based on scalability and determining the full set of causes for an inconsistency), and a performance measure (based on computational scalability). They show that their technique can determine the full set of expressions that cause model consistency problems both accurately and scalably. Given the prevalence of models well beyond software engineering, anyone interested in modeling tools, model inconsistency checking and resolution, and holistic and effective evaluation of engineering research should read this paper.

From subsets of model elements to submodels

Model-driven engineering (MDE) generalized the status of models from documentation or model-driven architecture (MDA) modeling steps to full artifacts, members of a so-called structured “model space”. We concentrate here on the submodel relationship which contributes a lot to this structuring effort. Many works and MDE practices resort to this notion and call for its precise characterization, which is the intent of this paper. A typical situation is model management through repositories. We start from the definition of a model as a set of model elements plus a set of dependency constraints that it asserts over these elements. This allows to isolate the notions of closed, covariant and invariant submodels. As a major result, we show that submodel transitivity can be guaranteed thanks to submodel invariance. This formalization offers keys to analyze operations which manipulate submodels. For example, we deeply study the operator which consists in extracting a model from another one, when selecting some subset of its elements. The same can be applied to many other model operations and the last part of the paper is dedicated to a synthesis on related works which could profit from this characterization. More practically, we show how the results were exploited in our Eclipse modeling environment.