Concurrent modeling in early phases of the software development life cycle
CRIWG'10 Proceedings of the 16th international conference on Collaboration and technology
Turning Conflicts into Collaboration
Computer Supported Cooperative Work
| Hi-index | 0.02 |
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.