The paper focuses on cooperation support in process-centred software development environments. A transaction-based approach is proposed, which supports and forces the cooperation of software developers by synchronizing the concurrent execution of development tasks. The proposed transaction concept uses the knowledge of a software process to avoid or resolve concurrency conflicts. Cooperation patterns are provided which can be applied for executing process transactions to control the concurrent execution of development tasks. The selection of the right cooperation pattern for a task depends on the task definition, the semantics of the accessed objects and the users' access rights, and in particular on the current project state.

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 …

Merlin2 is a prototype Process-centred Software Development Environment (PSDE), developed within the context of the Merlin project carried out at University of Dortmund in cooperation with STZ, a Dortmund based software house. This prototype uses a rule-based technique to describe and enact a software process. Users of Merlin are either software developers or managers who are involved in a software process to produce a product. A further kind of user or group of users respectively called the process engineer(s) are responsible for defining a particular process in terms of Merlin rules (or rather a dedicated process modeling language as will be explained later), i.e. they customize a Merlin PSDE to a particular software process or project. The major benefit of using an environment like Merlin for software production is sophisticated team support, i.e. support for coordinating access to shared information on different levels of granularity (e.g. from more or less complete systems of modules or documents down to a procedure definition in the export list of a single module), and dedicated message servers for broadcasting information about project states, (urgent) tasks to do, and getting feedback of completed work packages, etc. A further achievement of such an environment is the computer supported integration of development and management activities. For example, project managers are able to retrieve on-line information about the current project state at any time and developers are immediately informed about any necessary actions to be taken or any constraints applying to executing activities. This paper describes the main concepts behind the implementation of the Merlin prototype and sketches current and further work within the research project evolving from the current experience with the prototype.

The subject of this paper is the description of a process-centered software development environment called MERLIN which monitors and guides teams of software developers and managers in producing software objects. Software objects (or objects for short) include all sorts of documents like requirements analysis, design, code, user manuals, contracts etc. For each user, MERLIN automatically displays a specific working context which contains information like objects, their relations, their current development state, and corresponding tools. This information is filtered according to the (access) rights and duties a particular user has in a particular project, i.e. the working context depends on the user's role (e.g. programmer, designer, manager). Internally, the computation of the information to be contained in a working context, is based on a rulelike definition of a software process and a flexible interpretation mechanism to enact such a process definition. The main feature of the interpreter is an alternating use of backward and forward chaining for the interpretation of rules. In addition, our implementation enables a persistent storage and incremental update during runtime of all process information expressed in facts within the MERLIN knowledge base.

Some of many hard problems in current software production include the lack of proper organisational and tool supported models to manage large scale software production, the lack of integrated tools based on well-defined and commonly agreed integration mechanisms as well as the lack of formally based methods to allow to properly defined later re-usable software components 1