Specification of invariability in OCL

Kosiuczenko, Piotr

doi:10.1007/s10270-011-0215-y

Cited by 20 publications

(6 citation statements)

References 36 publications

(58 reference statements)

Supporting

Mentioning

Contrasting

Order By: Relevance

“…For validation and verification methods, however, it is also important which model elements may be changed or may not be changed in addition to the elements which are covered by pre-and postconditions. The determination of concrete behavior of an operation from the given pre-and postconditions is referred to in the literature as a the frame problem [BMR95] and can be addressed by additionally specifying so-called frame conditions [BKW09,Kos13,NPWD18] that explicitly characterize unchanged elements. The specification of frame conditions along with pre-and postconditions provides a complete description of the functionality of a model operation.…”

Section: Basic Ideamentioning

confidence: 99%

“…The major drawback of this approach is that it is time-consuming, as the frame conditions have to written manually and one has to maintain them later on in the case of design changes. The idea of the approaches in [Kos13,BKW09] is to specify the set of model elements that are allowed to be changed during an operation call together with the pre-and postconditions using so-called invariability clause (modifies only statements). However, the process of generating frame conditions for a model in terms of the invariability clause requires complete consideration of all model elements and their relationships.…”

Section: Related Workmentioning

confidence: 99%

“…However, sometimes they maybe not comprehensive enough to describe what may or may not be changed in a transition between two system states and could lead to unexpected behavior of an operation. As the solution of this problem, so-called frame conditions [BKW09,Kos13] have been proposed in addition to pre-and postconditions. However, frame conditions are usually written manually and could be cumbersome to write, as the model may contain a large number of elements which all have to be considered.…”

Section: Introductionmentioning

confidence: 99%

See 2 more Smart Citations

Developing Comprehensive Postconditions Through a Model Transformation Chain.

Desai¹,

Gogolla²

2019

JOT

View full text Add to dashboard Cite

One important approach for describing behavior in UML and OCL models is the use of OCL pre-and postconditions. This contribution proposes a new method for developing comprehensive OCL postconditions for operations in UML and OCL models, including so-called frame conditions. The method is realized by a transformation chain from an initial user-developed model into a semi-automatically derived test case model for checking the model quality. On the technical side, the method consists of a new formal distinction between deleted, sustained and added objects for operation behavior. On the methodological side, the development process is accompanied by a systematic case distinction, effective defaults and iterative improvement steps through test cases.

show abstract

Section: Basic Ideamentioning

confidence: 99%

Section: Related Workmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

Developing Comprehensive Postconditions Through a Model Transformation Chain.

Desai¹,

Gogolla²

2019

JOT

View full text Add to dashboard Cite

show abstract

“…There are a number of other OCL semantics (see the references in Cengarle and Knapp [11]). The semantics presented in this paper is a slight modification of the semantics defined by Bidoit et al [10] (see also [27]). The OCL semantics defined in the papers [11,10] strictly differentiate between UML queries and state-changing operations.…”

Section: Semanticsmentioning

confidence: 99%

“…, n. We say that t defines the scope of change of a, if, and only if, the following holds (cf. [26,27]…”

Section: Proofmentioning

confidence: 99%

On the Validation of Invariants at Runtime

Kosiuczenko¹

2013

Fundamenta Informaticae

Self Cite

View full text Add to dashboard Cite

The paradigm of contractual specification provides a transparent way of specifying objectoriented systems. In this paradigm, system consistency is specified using so-called invariants. Runtime validation of invariants is a complex problem. Existing validation methods require either exhausting validation of an invariant for all objects of the corresponding class or the use of restrictive type systems. In this paper a non-exhaustive method of invariant validation is proposed. It is proved that the method is sound and an implementation of this method is discussed. It is shown also how to extract context free languages corresponding to OCL-invariants. P. Kosiuczenko / On the Validation of Invariants at Runtime P. Kosiuczenko / On the Validation of Invariants at Runtime 185 which an invariant is evaluated can be treated as a root of such a network. If an invariant is violated by a method execution, then the corresponding network of objects is modified. We use extracted languages to navigate backwards from the modified places to the roots of invariants' networks.Since OCL is a very extensive language, we restrict our consideration to some core primitives and we prove our results for the restricted form of this language. Nevertheless, our results can be applied to a wide variety of invariants. Such invariants can include multiple variables, object-as well as class attributes, the allInstances feature and also recursively defined functions. The presented method allows us to identify invariants which have to be evaluated before and after method execution, and to identify objects for which the evaluation should be performed. It should be noted that our method does not depend on a particular definition of visible system states and therefore can be used with different definitions. The interesting thing is that we do not have to refer to all objects existing in the pre-state, but only to the roots of modified networks. Those roots can be defined by OCL-terms. We briefly discuss the issue of implementation, though it goes beyond the scope of this paper.This paper is organized as follows. The next section includes a short discussion of related work. In section 3, we discuss the problem of invariant validation, sketch our solution ideas and present two examples. In section 4, we show how to extract context free languages from OCL-terms and investigate the relation between such languages and OCL-terms. We also prove that terms formalizing words are well typed. In section 5, we prove that the problem of invariant validity can be reduced to the problem of preservation of object networks determined by languages corresponding to invariants; we show also how to express such languages using OCL-terms. In section 6, we show how the developed methods can be applied to the examples introduced in section 3. In section 7, we briefly discuss the issue of implementation. Section 8 concludes this paper.

show abstract