NDLI: Tolerating inconsistency ( ISPW '90 )

Please wait, while we are loading the content...

Review of the state-of-the-art (session summary)

Mechanisms (session summary)

Policies (session summary)

Data (session summary)

Control (session summary)

Emerging issues (session summary)

Tolerating inconsistency

Experiences with the spiral model as a process model generator

System dynamics models of software developments

Process programming and process models

Studying the process of software design teams

Process programming: a structured multi-paradigm approach could be achieved

Software process support through software configuration management

A structural framework for the formal representation of cooperation

The role of formalized domain-specific software frameworks

P4: a logic language for process programming

Software process instantiation and the planning paradigm

Modeling implications of the personal software process

Mechanisms for software process dynamics

Experience with Marvel

Experience with enactable software process models

Position paper for ISPW

The role of process models in software and systems development and evolution

A software process model based on unit workload network

Law-governed software processes

Product-based process models

A method for recording and analyzing design processes

Experiences with process programming

Acquiring experiences with executable process models

Software process dependability

Conceptual programming

Dynamics of process models in PML

Specification of software process measurement

Experiences with operational software process modeling in the system factory project

OPM: an object process modeling environment0

The software process as a goal-directed activity

Experiments with typing in process modeling

Domain understanding and the software process

An example of software development modelling

An example P4 process program for Rebus

GRAPPLE example: processes as plans

Marvel strategy language example

An example of process description in HFSP

Software process modeling example

An example of a software process model based on unit workload network

Example process program code, coded in Appl/A

Describing working environments in OPM

An overview of the ALF project

The Arcadia research project

ESF and software process modeling

Dynamics of process models in PML

Summary of software designer's associates project

Tolerating inconsistency ( ISPW '90 )

Content Provider	ACM Digital Library
Author	Balzer, Robert
Abstract	This is a short paper about a simple technique for making applications robust by marking data that violates specially identified invariants and using those marks as guards around code which is sensitive to that invariant.Such a capability is needed when dealing with the exceptions that arise in practical applications and distinguish them from idealized specifications. Previous techniques either required the removal of the constraint so that the exception would be allowed, or its modification to exclude the particular exception from the restriction.Our technique softens the entire constraint without introducing special cases, and is intended primarily for temporary exceptions. Rather than synchronizing all updates required by some constraint, it allows them instead to occur distributed in time in any arbitrary order. Thus, it is particularly useful in multiclient applications with shared responsibilities and authority, such as cooperative design (including software development).While the constraint is violated, the offending data is automatically marked by guards to screen it from, or identify it to, code segments sensitive to the violation. When the time distributed update is complete so that the data is no longer inconsistent, the guards are automatically removed so that the data can again be processed normally.The relevance of this work to the Process Workshop is that it provides a technique for relaxing the synchronization problem among multiple users cooperating on some compound update and allows them instead to operate asynchronously. That is, this technique allows us to write more realistic process programs describing the flexible time-distributed coordinations among agents without loosing the formal constraints on their shared goals. The cost of this flexibility is the conditionalization of the cooperating agents to tolerate these temporary inconsistencies.We have created two implementations of our technique for softening constraints to allow temporary inconsistencies. Both are fully automatic and both handle arbitrary constraints expressed in our first-order logic formalism. The first converts the original constraint into a pair of constraints that require the presence of the guards while the original constraint is violated and their absence otherwise. These new constraints have “repairs” which fix violations by respectively inserting or removing the guards. The second implementation replaces the original constraint by an inference rule which derives the guard if and only if the original constraint predicate was violated.Our contribution lies in formally representing constraints whose temporary inconsistency can be tolerated by an application, and in automatically marking the particular offending data while the constraint is being violated. The goal of minimizing the number and duration of such violations is informal and implicit. The task of identifying sensitive code segments and determining how they should respond to the temporary inconsistencies is likewise informal and manual.Our work has an interesting relationship with the recent work on transactions by Pu, Kaiser, and Hutchinson @cite(Split-Transactions) addressing the times and set of users over which a constraint applies. They, too, are interested in multi-party transactions, and have proposed “splitting” transactions into pieces with differing visibility scopes so that users in some group could see the changes made by the splits within the transaction, while those outside the group wouldn't see any changes until the entire transaction was committed.Split-Transactions can be viewed as another approach to exception handling. Rather than dealing with an exception or an inconsistency after a completed transaction, Pu, Kaiser, and Hutchinson subdivide the transaction so that the multi-party coordinations can occur within it. As in all transactions, constraints are only applied when committed. Thus, during the transaction the effect is to remove the constraints.The power of the Split-Transaction approach is the scoping (potentially multi-level) that it provides to allow groups to cooperatively prepare a compound update for a broader community. However, within the transaction, since the constraints are not in effect, the inconsistency is not explicit, and hence cannot be tracked, managed, or supported except by informal mechanisms outside the system.But there is no reason why Split Transactions couldn't be combined with our own techniques for tolerating inconsistency to provide the advantages of both. While the inconsistency existed, it would be guarded by Pollution Markers, but it would only be visible to the group (dynamically formed) needed to resolve that inconsistency. After it was resolved, the Pollution Markers would be removed, and the new consistent state would be visible outside the group.
Starting Page	41
Ending Page	42
Page Count	2
File Format	PDF
ISBN	0818621044
Language	English
Publisher	Association for Computing Machinery (ACM)
Publisher Date	1990-10-01
Access Restriction	Subscribed
Content Type	Text
Resource Type	Article

Central Library (ISO-9001:2015 Certified)
Indian Institute of Technology Kharagpur
Kharagpur, West Bengal, India | PIN - 721302

See location in the Map
03222 282435
Mail: support@ndl.gov.in

Sl.	Authority	Responsibilities	Communication Details
1	Ministry of Education (GoI), Department of Higher Education	Sanctioning Authority	https://www.education.gov.in/ict-initiatives
2	Indian Institute of Technology Kharagpur	Host Institute of the Project: The host institute of the project is responsible for providing infrastructure support and hosting the project	https://www.iitkgp.ac.in
3	National Digital Library of India Office, Indian Institute of Technology Kharagpur	The administrative and infrastructural headquarters of the project	Dr. B. Sutradhar bsutra@ndl.gov.in
4	Project PI / Joint PI	Principal Investigator and Joint Principal Investigators of the project	Dr. B. Sutradhar bsutra@ndl.gov.in Prof. Saswat Chakrabarti will be added soon
5	Website/Portal (Helpdesk)	Queries regarding NDLI and its services	support@ndl.gov.in
6	Contents and Copyright Issues	Queries related to content curation and copyright issues	content@ndl.gov.in
7	National Digital Library of India Club (NDLI Club)	Queries related to NDLI Club formation, support, user awareness program, seminar/symposium, collaboration, social media, promotion, and outreach	clubsupport@ndl.gov.in
8	Digital Preservation Centre (DPC)	Assistance with digitizing and archiving copyright-free printed books	dpc@ndl.gov.in
9	IDR Setup or Support	Queries related to establishment and support of Institutional Digital Repository (IDR) and IDR workshops	idr@ndl.gov.in