Cooperation Patterns for Process-Centred Software Development Environments.

perfectly possible to implement our process transactions in MSL exploiting the language constructs of the PCCP. Furthermore, none of the discussed approaches provides the possibility to choose different but predefined conflict resolution strategies depending e.g. on the project's state or the context (i.e. user, role, related documents etc.) as exemplified in section 2. Thus, the best of our knowledge, our approach is the only one which offers the user the possibility to choose (at least in certain cases) on the fly the most suitable type of transaction. A major piece of work is to integrate a version and configuration management component in Merlin, i.e. to improve Merlin's support for cooperation by enabling the specification of a particular version and corresponding configuration model within the Merlin modelling language. This again means extending the Kernel level with rules which fix a basic VM/CM model and then provide a number of predefined predicates which are used to define a particular process or project-specific VM/CM model [19]. A further effort is geared towards improving the architecture with respect to distribution, as indicated in [20]. The main idea is to have, in addition to distributed process interpreters, partly distributed process data. This, of course, requires more sophisticated synchronisation policies which keep the process data in a consistent state. The communication which is needed to keep this consistency will be supported by a sophisticated message server which is also under investigation. Acknowledgements We gratefully acknolwledge the detailed comments of Olaf Neumann and Sabine Sachweh when revising the first version of this paper. We are also indebted to the other members of the Merlin project, namely Wolfgang Emmerich, Jens Jahnke and Burkhard Peuschel who have contributed a lot to the project through many fruitful discussions. Furthermore, we gratefully acknowledge the implementation work of a number of master students who brought the current version of the prototype into existence. Those theses include the work of As an example consider fact doc_relation_requires_wctr shown in figure 5. This fact prescribes the application of wcCP-transactions, if the working context of a designer contains two specifications linked by an use relationship. In that situation the execution of a transaction of type wcCP ensures that no other user can get inconsistent views on the specifications (which would happen if one already modified specification and one specification not yet modified would be accessed). Further examples are given in figure 6. Fact allow_parallel_access allows the …