The paper discusses two aspect of collaboration in software engineering. The rst one focusses on methodological support for collaborative modelling and the second one on the speci cation of collaborative activities and their simulation. For both aspects links to the literature are provided and existing tool support is discussed. The language CoTaL and their simulation environment CoTaSE are shortly introduced.
Professional software development is most of the time a collaborative activity.
Only in very rare situations software is developed by one person only. There
are several studies on collaborative programming like [
This section describes a study [
Di erent class diagram designs can be re ected at runtime to compare alternatives for certain design solutions. Ongoing investigation is made on improving design processes by supporting teams with di erent strategies. One strategy can be to guide sessions for structuring processes at all. However, tool support for multiple designers of collaborative teams di ers from tool support for single designers.
Software that can be used for collaborative design sessions must satisfy needs of persons and groups as well. The analysis (Fig. 1) has shown that software requirements exist not only for collaborative but also for individual support. This results in a user interface that is shown in Fig. 2. Individual designers have their own personal spaces for editing classes, relations, and notes of models.
All personal spaces are equipped with toolbars and software keyboards that support making edits. The group space shows designed class diagrams and allows designers to adapt layouts. Classes, relations, and notes of diagrams can be blocked by designers that select them in the group space. This strategy helps to avoid con icts when editing elements.
Individual support for designers is integrated to the user interface of this software prototype. Personal spaces could also be provided on di erent devices what is part of other studies. However, the problem of merging models that come from more than one participating designer arises when targeting the functionality of how to deal with con icting model elements. The same problem arises when designers try to merge di erent forks of alternative models designs. Solutions for this problem are parts of ongoing studies. However, the process of designing models with class diagrams also is a ected by the expertise of participating designers.
Design sessions can be structured in di erent ways. Most of the time designers are on their own and the problem can arise that the design process is getting unstructured. Moderators can facilitate design sessions in a way that they guide the process to open up unknown domains in a more structured way. However, also moderators must have a certain expertise to help participants in designing domain-speci c models. Another solution can be to make rules for designers on how to behave in collaborative design sessions. These rules need to be identi ed by comparing the results coming from structured and unstructured sessions, what is part of ongoing studies. 3
The software under development often has to support collaborative activities as
well. Therefore, it is necessary to have precise speci cations for these activities.
Some of our studies recognized that current task models and business process
speci cations [
Based on the concept of task models [
Besides the language CoTaL an environment CoTaSE [
Speci cations can be in depth validated before implementing the software. An
overview of the language and its application to smart environments is provided
in [
\An employee lls in a holiday application form. He/She puts in a start and
end date of his/her vacation. The responsible manager checks the application
and informs the employee about his/her decision; the holiday request might be
rejected or get approved. In case of approval the holiday data are sent to the
human resource department which updates the days-o in the holiday le." ([
From the text one can identify three roles: Employee, Manager, and Human Resources (HR). A task Process request is identi ed for the manager. It has to be of type instance iterative. Otherwise, a manger would only be able to accept one request at any time. According to the provided speci cation below, there has to be at least one instance iteration. Additionally it is speci ed that there is no maximal number of requests (-1 represents the in nite symbol).
Three variables E1, M1 and H1 are declared and bound to the context C1.
In this way, the instance of the employee that requests a vacation
(bindVarTask = \E1.Ask") is stored in variable E1. This has the consequence, that
the task \GoOnVacation" is restricted to the same Person by \bindVarTask =
E1.GoOnVacation". These details are often neglected in business process
specications. They often do not specify such details. Some comparisons of business
process speci cation examples are provided in [
It seems to be obvious, that such details of speci cations are very important for the implementation of corresponding software systems. They should be analyzed and clari ed during the requirements analysis activities. </t a s k > </taskmodel >
The initially animated models of the vacation request example are provided by Fig. 4 and Fig. 5. Green circles signal that the corresponding task can be executed. If a read circle is attached to the green one this means that in principle (according to the own temporal relations) the task of the model instance could be executed. However, certain constraints are not ful lled. For Fig. 4 human resources has to announce rst that holidays are approaching. Employees can ask for vacation afterwards and managers can process requests after they were formulated.
In the upper part of Fig. 4 on can the see the model that describes the collaboration. We call it team model. It exists only once. All other models are role models and di erent instance can exist. In the example above there are two managers Regina and Marco. Additionally, there are two employees Mary and Peter. For human resources there is only on instance that is called Janet. The simulation environment CoTaSE allows the dynamic creation of further role model instances at any time. In this way constraints can change.
Let us create a further role instance for employee that is called Paul. We will have a look at the model instances after the rst vacation request was created.
Already from the team model one can imagine that in parallel to request one there might be the next one processed in parallel. One can also see that manager Regina made her rst decision. She accepted a request. The request came from Mary who can go on vacation now. Regine could manage the second request. However, there is no further request available. A request from Paul or Peter could be processed by Regina or Marco. 3.2
While analyzing existing language and tools for task models a lack of support for specifying cooperative work was identi ed in the domain of smart meeting rooms. A new speci cation language CoTaL was introduced that extends features of task models in such a way that more precise speci cations are possible.
Each role is speci ed by a task model. The communication between roles is characterized by a speci c task model that is called team model. It re ects the activities of all actors and exists only once. Each actor is associated with one or more role model instances.
The speci cation of task models specifying cooperative activities was extended by context de nitions. Within such task context, variables can be de ned. They allow the storing of references to instances of roles. A language CoTaL is provided for this purpose. This language and its interpreting environment CoTaSE were discussed.
The environment CoTaSE allows the dynamic instantiation of task models during runtime which is an important feature for the application of task model speci cations for smart environments and cooperative work in general. It implements the temporal operator of instance iteration. Additionally, it provides the feature of ending and starting tasks (in contrast to executing tasks as an atomic action, i.e. a task execution that takes place at a speci c point of time instead of a time span t = tend tstart) which is important for simulating parallel activities. Tasks can have preconditions, start triggers, and end triggers. Scenarios can be created that are useful for testing the nal application or for other duties. It is for instance possible to generate a series of scenarios that are used to construct new versions of task models. 4
Two di erent aspects of collaboration in software engineering were discussed. The rst one focusses on collaborative modelling, which is not very well understood yet. More precise methodological support seems to be necessary in the future. This has to go together with corresponding tool support. Additionally, speci cations were discussed that allow precise descriptions of collaborative work. Also for this aspect more conceptual work and tool support are necessary. It would be a challenge for the future to describe the activities in collaborative modelling by corresponding task models.