Balzer, R.: Tolerating inconsistency. In: ICSE '91: Proceedings of the 13th international conference on Software engineering, Los Alamitos, CA, USA, IEEE Computer Society Press (1991) 158--165  Home/Search   Document Not in Database   Summary   Related Articles   Check

....not explicitly applied nor specialized to consistent (conflict free) query answering in databases. Complexity issues are not addressed. Further related treatments of inconsistency have been developed in the areas of knowledge representation [44] and formal specifications in software engineering [12,85]. 7.3 Databases The approaches discussed here and in the next subsection are applicable to relational databases and to first order queries and integrity constraints. Asirelli et al. 11] treat integrity constraints as views over a deductive database. In that way, queries can be answered ....

B. Balzer. Tolerating Inconsistency. In 13th International Conference on Software Engineering, pp. 158--165. IEEE Computer Society Press, 1991.

....Process deviation As pointed out by Cugola et al. 32] the e#ort required to change a project plan makes this approach unsuitable to coping with situations that require minor or temporary deviations. Instead of requiring alignment of a plan every time a deviation occurs, some researchers (e.g. [37], 38] 39] 40] 32] propose tolerating deviations and allowing inconsistencies to exist. In other words, performances can explicitly diverge from plans. The bulk of the literature on deviation tolerant models is focused on inconsistent states in artifacts, a problem that is particularly ....

R. Balzer, Tolerating inconsistency, in: L. Belady, D. Barstow, K. Torii (Eds.), Proceedings of the 13th international conference on Software engineering, IEEE Computer Society Press, Austin, Texas, 1991, pp. 158--165.

....w.r.t. Ri. consistency of Ri D, and monotonicity of domain descriptions) can be interpreted as validation checks that can (and should) be made during requirements evolution in order to identify and expose possibly latent errors. Once such errors are exposed, they can be tolerated (as advocated by [1,5,6,9,13]) if they reflect a genuine conflict of goals or simply there is not enough information available yet to decide how to correct them, or corrected immediately by changing the relevant requirements or domain model elements. In any case, an informed decision can be taken only after such cases have ....

Balzer R., "Tolerating inconsistency", Proc of the 13 t IEEE International Conference on Software Engineering (ICSE 13), pages 158-165, Austin, Texas, (1991), IEEE Comp Soc Press.

....not explicitly applied nor specialized to consistent (conflict free) query answering in databases. Complexity issues are not addressed. Further related treatments of inconsistency have been developed in the areas of knowledge representation [43] and formal specifications in software engineering [12,84]. 7.3 Databases The approaches discussed here and in the next subsection are applicable to relational databases, and first order queries and integrity constraints. Asirelli et al. 11] treat integrity constraints as views over a deductive database. In that way, queries can be answered through ....

B. Balzer. Tolerating Inconsistency. In International Conference on Software Engineering, pages 158--165. IEEE Computer Society Press, 1991.

....by providing different viewpoints. Diagrams have in common that they break up software development into smaller, more comprehensible pieces utilizing a divide and conquer strategy. These pieces are related in the system they describe and, combined, they form a model description of a system [2]. The major drawback of diagram centric software engineering is that development concerns cannot be truly investigated individually since they tend to affect one another. If a set of issues about a software system is investigated, each through its own set of diagrams then their combined ....

....levels of abstraction (i.e. high level versus low level diagrams) Our approach, called VIEWINTEGRA, is primarily aimed at detecting inconsistencies after they have been introduced. We take the stance that software diagrams are inherently ambiguous and inconsistencies often cannot be avoided [2,4]. In this paper, we will emphasize the important nature of transformation as a means of improving consistencychecking scalability. It is our finding that consistency checking between n diagrams does not require n n number of transformations and or comparisons but significantly fewer. It is ....

[Article contains additional citation context not shown here]

Balzer, R., "Tolerating Inconsistency," Proceedings of 13th International Conference on Software Engineering (ICSE-13), pp. 158-165, May 1991.

....In section 4, we describe how the approach of Kifer and Lozinskii [50] can be adapted to the task of computing consistent query answers. Related treatments of inconsistency have been developed in the areas of knowledge representation [32] and formal specifications in software engineering [11, 67]. 7.3 Databases Asirelli et al. 10] treat ICs as views over a deductive database. In that way, queries can be answered through the views , in such a way that the resulting answers satisfy the ICs, and answers that do not satisfy them are filtered out. This approach is the closest to the ....

Balzer, B. Tolerating Inconsistency. In Proceedings of the 13th International Conference on Software Engineering (ICSE'91), IEEE Computer Society Press, 1991, pp. 158-165.

.... itself become a topic, for a survey we refer to [28] and for a research agenda to [17] The tolerant approach to inconsistency, which asserts that inconsistency cannot be eradicated in any su#ciently complex system, but must be monitored nonetheless, was first seen in the area of databases in [4]. This tolerant approach gains special significance in our scenario of distributed specifications, as enforcing total consistency becomes even less feasible. A viewpoint [19] allows developers to express a design fragment in some specification language, together with additional attributes ....

R. Balzer. Tolerating Inconsistency. In Proceedings of the 13th International Conference on Software Engineering, pages 158--165, Austin, TX USA, May 1991. IEEE Computer Society Press.

....be difficult, and it is therefore preferable to allow inconsistencies to occur, and to resolve them periodically rather than prevent them. Narayanaswamy Goldman [16] also present an incremental inconsistency handling solution based on announcing and interleaving proposed changes , while Balzer [1] introduces the notion of pollution markers to flag portions of program code that contain inconsistencies which can be circumvented in order to continue development. Inconsistency can be used to identify areas of uncertainty. If a team of developers work together on a set of descriptions, then ....

....in each case was to re represent and re structure the specifications more precisely, more formally and at different levels of abstraction, in order to permit more detailed analysis than would otherwise have been possible. In the first study, we used two formal notations, SCR [10] and PROMELA [1 1] for verifying portions of the Fault Detection, Isolation Recovery (FDIR) requirements for the control of a communications bus. This study demonstrated that translating the informal specifications into a formal notation helps identify ambiguities and inconsistencies, and allows some of the ....

R. Balzer, "Tolerating Inconsistency", Proceedings of 13th International Conference on Software Engineering (ICSE-13), 158-165, Austin, Texas, USA, IEEE Computer Society Press.

....and even suggest the actions needed to reconcile the actual process and the process model. To the best of our knowledge, SENTINEL [23] is the first example of a PSEE that supports case 3 deviations. The approach adopted by SENTINEL to manage inconsistencies has been inspired by the work of Balzer [3], which set the initial stage for research efforts aiming at tolerating inconsistencies in PSEEs. Process model PSEE Case 2: unmanaged deviation 3: managed deviation 1: on the fly change Reconciling Actual process Figure 6: Possible approaches to cope with unexpected situations during ....

R. Balzer, "Tolerating Inconsistency". In Proceedings of 13th International Conference on Software Engineering, Austin (Texas - USA), May 1991.

....needs, and ideally can be delivered on time. Since inconsistency in software is problematic, management of consistency must be given a high priority in software development in general and in RE in particular. In recent years, tolerating inconsistency has been advocated by several researchers (e.g. [4, 8, 9]) Some approaches have also identi ed the need to enable reasoning and performing actions to continue in the presence of inconsistency [14] Whatever approach one may take in dealing with inconsistency, it is clear that rst and foremost inconsistencies have to be discovered and analyzed. ....

....explored before a decision is made. Such parallel exploration of several internally consistent, but mutually inconsistent, belief systems may of course, give an external observer the illusion of a single inconsistent system [16] This is precisely what the advocates of tolerating inconsistency [4, 8, 9] have been interested to achieve. In a way, what is being achieved here is well beyond just tolerating inconsistency in that it also involves delaying the resolution of inconsistencies, which is what our formal framework supports intrinsically. By holding on to the requirements that are ....

R. Balzer. Tolerating inconsistency. In Proceedings of the 13th International Conference on Software Engineering (ICSE-13), pages 158-165, Austin, Texas, 1991. IEEE Computer Society Press.

....can be difficult, and it is therefore preferable to allow inconsistencies to occur, and to resolve them periodically. Narayanaswamy and 1 pronounced Ki bel Goldman [16] describe an incremental inconsistency handling solution based on announcing and interleaving proposed changes , while Balzer [2] introduced the notion of pollution markers to flag portions of program code that contain inconsistencies. Inconsistency has also been studied in the context of process modeling. Cugola [7] argues that process improvement can be achieved by allowing deviations from the prescribed process, and by ....

R. Balzer. "Tolerating Inconsistency". In Proc. 13th Int. Conf. on Software Engineering (ICSE-13), pages 158--165, Austin, Texas, USA, 1991. IEEE CS Press.

....highly applicable to Software Engineering and that their investigation and application to Software Engineering is long overdue. It is time for Software Engineering to catch up with its more mature counterparts in traditional elds of engineering. Software Engineering problems are often typi ed [4, 3, 10, 27, 26, 30, 35] by the observations paraphrased below: There is usually a need to balance competing constraints. Occasionally there is a need to cope with inconsistency. There are often many potential solutions. There is typically no perfect answer . but good ones can be recognised. There are sometimes ....

Balzer, R. Tolerating Inconsistency (Software Development). In Proceedings of the 13th International Conference on Software Engineering (May 1991), pp. 158-165.

....to the ISPW6 7 example, showing how it is possible to measure the correspondence between a model of this process expressed as a Petri net and different examples of process execution. As for the general issue of tolerating and supporting inconsistencies, pioneering work was described by Balzer [3]. This seminal work argues for the need to tolerate (domain level) inconsistencies and proposes pollution markers as a mechanism for describing and controlling them. The author presents a technique to automatically relax integrity constraints formulated as logical sentences in order to allow their ....

R. Balzer. Tolerating inconsistency. In Proceedings of the 13th International Conference on Software Engineering, Austin (Texas - USA), May 1991.

....constraints. Both solutions are unacceptable in our case. In fact, we want to tolerate deviations and, at the same time, we want to identify the transitions that produced deviations (i.e. we cannot eliminate constraints) Our solution has been inspired by the approach proposed by Balzer [2]. Balzer relaxes a constraint Q by substituting it for a new formula, stating that a new condition P , called Pollution Marker, holds if and only if Q does not hold. The new formula has the form: P (x1 ; Delta Delta Delta ; xn) Q(x1 ; Delta Delta Delta ; xn) 2) Given that constraint Q ....

Robert Balzer. Tolerating Inconsistency. In Proceedings of the 13th International Conference on Software Engineering--ICSE 13. IEEE Computer Society, 1991.

....be difficult, and it is therefore preferable to allow inconsistencies to occur, and to resolve them periodically rather than prevent them. Narayanaswamy and Goldman [16] describe an incremental inconsistency handling solution based on announcing and interleaving proposed changes , while Balzer [2] introduces the notion of pollution markers to flag portions of program code that contain inconsistencies which can be circumvented in order to continue development. Inconsistencies may indicate deviations from a process model. Cugola [7] argues that process improvement can be achieved by ....

R. Balzer. "Tolerating Inconsistency". In Proceedings of 13th InternationalConference on Software Engineering (ICSE-13), pages 158--165, Austin, Texas, USA, 1991. IEEE Computer Society Press.

....respect to the consistency constraints of the software process. RBDE marks these objects and stores information about the nature of the inconsistency (i.e. the value of an attribute is inaccurate) and how to re establish consistency. This is similar to Balzer s notion of tolerating inconsistency [Balzer 91] 16 Although control rules can prescribe actions that enable RBDE to temporarily tolerate the inconsistency of some objects, they have no way of guaranteeing that the consistency of these objects will be re established later. We introduce the notion of obligations, which when satisfied ....

....mechanism that allows multiple developers to change the project database concurrently. Changes to the same objects in the database are then merged to produce a consistent version of the database. Our notion of tolerating inconsistency is based on Balzer s notion of tolerating inconsistency [Balzer 91] which, we assume, will be integrated with CLF at some point. We have partially implemented our thesis work in MARVEL; we have implemented enough of the work to be able to identify some subtle points that have been ignored so far by the process centered SDE community, such as the exact nature ....

Balzer, R. Tolerating Inconsistency. In 13th International Conference on Software Engineering, pages 158-165. IEEE Computer Society Press, Austin, TX, May, 1991.

.... and enable cooperation [7] Coordination modeling seriously complicates both failure recovery and process evolution, because it may introduce commit and abort dependencies among top level transactions [10] and the possibility of relatively long lived temporary inconsistency in the objectbase [2]. This is the subject of ongoing research. 4. Data Model Evolver To evolve an objectbase, the administrator simply edits the data model and runs the Evolver tool. One alternative considered in the design phase was to alter classes through an interactive dialog with the Evolver. This was ....

Robert Balzer. Tolerating Inconsistency. In 13th International Conference on Software Engineering, pages 158-165. IEEE Computer Society Press, Austin TX, May, 1991.

....performed by different developers by the following two main functions: a) it detects inconsistent states between artifacts in PVC and in FVC; b) it propagates a mark to all the dependent artifacts to notify a possibility of inconsistencies. Our PMM is based on Pollution Marker proposed by Balzer[1], and the applied method of Pollution Marker to tolerate deviation from the process description by Cugola et al. 4] Wewould like to improve the following situations by PMM: a) when we prepare for a predicted future change, we usually presume a configuration of versions at the time of check in; ....

Balzer, R.: Tolerating Inconsistency. Proc. of ICSE-13, (1991), pp. 158 - 165.

....that requirements that would otherwise be discarded in an evolution step are maintained in a background store in anticipation of future reuse. Our goal in this paper is to develop a formal framework with these characteristics. There is a large body of earlier work that this research builds on. Balzer #Balzer 1991# introduced the notion of pollution markers as an approach to tolerating and managing inconsistency in speci#cations. The Viewpoints framework #Finkelstein et al. 1992# #Nuseibeh, Kramer, Finkelstein 1994# #Finkelstein et al. 1994# #Easterbrook et al. 1994# supports multi perspective ....

Balzer, R. 1991. Tolerating inconsistency. In Proceedings of the 13th Int'l Conference on Software Engineering, 158#165.

....the techniques developed are based on rigorous consistency checking and analysis, in an attempt to eradicate inconsistencies as soon as or soon after they are detected. However, in practice, inconsistency is inevitable in real large scale specifications [Schwanke Kaiser 2 88; Balzer 91; Cugola et al. 96] Living with inconsistency during evolutionary development is a fact of life. Therefore, inconsistency handling mechanisms are needed to support incremental evolution of specifications. By this we mean identifying changes that address some specification inconsistencies, while ....

R. Balzer, "Tolerating Inconsistency", IEEE Proceedings of 13 th International Conference on Software Engineering (ICSE-13), Austin, Texas, 1991.

....as neglecting the nature of conflicts as a productive source of creativity. Authors from the software engineering community noticed that multiple stakeholders pursue conflicting opinions, have contradicting requirements and 1 2 Hans W. Nissen and Matthias Jarke alternative perspectives [4, 17, 14]. In consulting practice, such approaches have been pursued for a long time, albeit without much computer support. Prominent examples include IBM s JAD (Joint Application Design) 3] SSM (Soft Systems Methodology) 11] and PFR (Analysis of Presence and Future Requirements) 1] Such ....

....module where all models of the coordinated modules are accessible. All the mechanisms we present in this section therefore apply to both the single perspective check and the cross perspective check. 5.1. Detection of Inconsistencies Like other approaches that deal with inconsistency detection [50, 4, 19] we use rules instead of closed formulas: For an integrity constraint we assume an inconsistency view 0 ) incons where incons is a new predicate symbol and 0 is a closed formula. incons is deducible if and only if fails, i.e. 0 is the negation of . We call an object that is ....

[Article contains additional citation context not shown here]

R. Balzer. Tolerating inconsistency. In Proc. of the 13th Intl. Conf. on Software Engineering (ICSE-13), pp. 158--165, Austin, Texas (1991).

No context found.

Balzer, R.: Tolerating inconsistency. In: ICSE '91: Proceedings of the 13th international conference on Software engineering, Los Alamitos, CA, USA, IEEE Computer Society Press (1991) 158--165

No context found.

R. Balzer, Tolerating inconsistency, in: Proceedings of the 13th IEEE International Conference on Sofware Engineering (ICSE13), IEEE Computer Society Press, Austin, Texas, 1991, pp. 158--165. 30

No context found.

R. Balzer. Tolerating Inconsistency. In Proceedings of the 13th International Conference on Software Engineering, pages 158--165, Austin, TX USA, May 1991. IEEE Computer Society Press.

No context found.

Balzer, R.: "Tolerating Inconsistency," Proceedings of 13th International Conference on Software Engineering (ICSE-13), pp. 158-165, May 1991.

First 50 documents  Next 50

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC