=Paper=
{{Paper
|id=Vol-344/paper-16
|storemode=property
|title=COMA: A Tool for Collaborative Modeling
|pdfUrl=https://ceur-ws.org/Vol-344/paper16.pdf
|volume=Vol-344
|authors=Peter Rittgen
|dblpUrl=https://dblp.org/rec/conf/caise/Rittgen08
}}
==COMA: A Tool for Collaborative Modeling==
https://ceur-ws.org/Vol-344/paper16.pdf
COMA: A Tool for Collaborative Modeling
Peter Rittgen
University College of Borås, 501 90 Borås, Sweden
peter.rittgen@hb.se
Abstract. 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.
Keywords: Group modeling, model negotiation, collaboration support
1 Introduction
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 [1]). Some notable
exceptions such as [2] are out of date or do not address consensus building [3, 4]. Our
objective is to support information synthesis and negotiation as two of the corner-
stones of collaborative modeling [2]. The tool and the architecture are the result of a
study of modeling behavior [5] and they have been tested in two case studies. Details
on these cases are currently under review for publication.
2 Architecture of a Collaborative Modeling Support System
[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
62 Proceedings of CAiSE’08 Forum
or personal version of the model the modeler can make use of bits and pieces of
existing versions (i.e. group model or other proposals), or even copy a whole version
and apply changes to it.
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.
3 The COMA Tool
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 right-
click 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
Proceedings of CAiSE’08 Forum 63
deleted. The proponents of the rejected proposals can resubmit them in the new round,
possibly after applying some changes.
Fig. 1. Screenshot of the COMA tool
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
64 Proceedings of CAiSE’08 Forum
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.
References
1. Conklin, J., Selvin, A., Buckingham Shum, S., Sierhuis, M.: Facilitated Hypertext for
Collective Sensemaking: 15 Years on from gIBIS. In: Weigand, H., Goldkuhl, G., de Moor,
A. (eds.): Proceedings of the 8th International Working Conference on the Language-Action
Perspective on Communication Modeling (LAP'03), Tilburg, The Netherlands (2003)
2. Dean, D., Orwig, R., Lee, J., Vogel, D.: Modeling with a group modeling tool: group
support, model quality, and validation. Proceedings of the Twenty-Seventh Hawaii
International Conference on System Sciences. Vol.IV: Information Systems: Collaboration
Technology Organizational Systems and Technology, 4-7 Jan 1994, Vol. 4. IEEE Computer
Society Press, Los Alamitos, CA (1994) 214-223
3. Pereira Meire, A., Borges, M.R.S., Araújo, R.M.d.: Supporting multiple viewpoints in
collaborative graphical editing. Multimedia Tools and Applications 32 (2007) 185 - 208
4. Santoro, F.M., Borges, M.R.S., Pino, J.A.: CEPE: Cooperative Editor for Processes
Elicitation. Proceedings of the 33rd Hawaii International Conference on System Sciences -
Volume 1. IEEE Computer Society (2000)
5. Rittgen, P.: Negotiating Models. In: Krogstie, J., Opdahl, A., Sindre, G. (eds.): Advanced
Information Systems Engineering, 19th International Conference, CAiSE 2007, Trondheim,
Norway, June 2007, Proceedings. Springer, Berlin (2007) 561-573
6. Frederiks, P.J.M., Weide, T.P.v.d.: Information Modeling: the process and the required
competencies of its participants. Data & Knowledge Engineering 58 (2006) 4-20
7. Dean, D.L., Orwig, R.E., Vogel, D.R.: Facilitation Methods for Collaborative Modeling
Tools. Group Decision and Negotiation 9 (2000) 109-127