Building on earlier empirical work we have designed a prototype that supports modeling in groups. The COllaborative Modeling Architecture tool (COMA tool) coordinates UML modeling in groups in the form of a negotiated creation process. We have employed the tool in two case studies. [2] identifies the cornerstones of collaborative modeling as information gathering, synthesis of information and negotiation. According to [6] the primary medium for information gathering is natural language and the organizational form is often that of a chauffeured session [7]. Tools for this already exist [1]. Information synthesis alone is also supported by a large amount of tools, namely by most conventional diagramming, modeling or CASE tools. But there is so far no current tool addressing the negotiation of models. The COMA tool provides this functionality while also allowing for information synthesis. For the latter we have made use of an existing UML modeling tool (UML Pad). Distributed model negotiation means the coordination of the efforts of a number of modelers. The results from the empirical study suggest that such a system must provide the following functions: Propose, support, challenge and accept. A proposal is a suggestion for the revision of the current version of the model. It implies that the modeler posts the content of the local model editor to the group. In building the local
The nature of modeling as a collaborative process is widely accepted. Nevertheless,
most of the tools that support modeling are single-user tools. This is even true for
tools that explicitly address group modeling (e.g. Compendium [
A support is a positive assessment of a proposal. It can be logged by any team member after reviewing the respective proposal. It can be complemented by a comment that provides a rationale for the decision and perhaps includes suggestions for minor changes.
A challenge is a negative assessment of a proposal. It has to be complemented by a justification for the decision as well as constructive comments regarding improvements of the proposal.
COMA offers two rules to decide on the acceptance of proposals: A rules of majority and a rule of seniority. When a rule of majority is used, the team operates in an unfacilitated mode where each modeler has a vote of the same weight. Acceptance only depends on the number of supports and challenges. The rule specifies the minimum number of supports required, and the maximum number of challenges allowed for a proposal to be accepted. The required number of supports should be at least two to avoid that a modeler alone (e.g. the proponent) can make the decision. A maximum number of challenges of 0 would force a unanimous decision. When a rule of seniority is applied, the team has a facilitator that makes the decision. Other group members cannot directly influence the decision, but they can do so indirectly by making suitable comments (i.e., supports and challenges). The facilitator can and should consider the supports and challenges in the decision.
The COMA tool is divided into three working panes (see Fig. 1). The upper one shows the current version of the group model and serves as a point of reference, e.g. for copying and pasting stable parts of the model for building a new version locally. The contents of this pane cannot be edited, hence the grey background. The lower left pane is the editor window where a user can draw the own diagram, possibly with the help of parts that have been copied from the group model or proposals by others. If the user considers the own local model finished she can save it and make it a proposal by right-clicking on the background and choosing “Propose model” from the context menu. This makes it available for others to load into their proposal panes.
The lower right pane represents the said proposal pane. Here the user can load one of the proposals made by the other group members or even the own proposal. A rightclick on the background reveals a context menu that allows for logging a support or challenge for this proposal. In the same menu the user can also request a negotiation window that will pop up and display details on the status of the negotiation. These details include the lists of supports and challenges where each entry contains the name of the supporter/challenger and the rationale, i.e. the reason for the decision, and in the case of a challenge also suggestions for improvement.
If sufficient support for a proposal is available, the negotiation window can also be used to accept the proposal. This turns the proposal into the new version of the group model and starts a fresh modeling round. This implies that all the other proposals are deleted. The proponents of the rejected proposals can resubmit them in the new round, possibly after applying some changes. Fig. 1 shows a snapshot of the modeling process at a certain stage. This is supposed to give the reader an example of how modeling in COMA proceeds. The group was in charge of developing a model for the handling of so-called problem goods, i.e. goods with an unclear recipient. In a first step they simply wrote down all the activities that are involved thus arriving at the first version V001 (upper pane).
One member, Peter, knows from experience that the activities are performed in a certain sequence. He draws the respective diagram by copying all elements from the upper pane and simply adding the arrows and rearranging the objects. He proposes this diagram and thereby makes it accessible to the other group members who can now comment on it or also suggest their own versions.
Jenny, the group member from whom the screenshot in Fig. 1 was taken, decides to load Peter’s proposal in her proposal pane (the lower right one). She takes a closer look at it and agrees with the principle sequence but she is quite sure that the search for the recipient is terminated as soon as the recipient is identified and that further steps are skipped. She draws the respective diagram in her local editor window (lower left pane) and makes a counter-proposal.
When comparing the two competing proposals the other group members decide that Jenny’s proposal is more in line with the actual procedure and they log respective supports for her proposal. The new proposal was subsequently adopted by the group as version two.
Although not a business modeling language, we have chosen the UML as the basis for the COMA tool. This decision was driven by a number of factors. Firstly, the UML is a standardized language with considerable impact in the information systems industry. Secondly, some of the diagrams, e.g. Use Case and Activity Diagrams, are often used for business process modeling as companies want to leverage the benefits of a common language for both business analysis and IT design. Another reason is the ready availability of open-source modeling tools that reduce the investments in tool development.
The tool is implemented in Visual C++ 2005 on Windows based on the UML Pad by Luigi Bignami (bignamil@tiscali.it) and with the wxWidgets GUI library (http://www.wxwidgets.org/). It is available for download at http://www.COMA.nu.