A System for Collaborative Building of Use Case Models:

Communication Analysis and Experiences

Experiences of Use and Lessons Learned from the Use of the SPACE-DESIGN

Tool in the Domain of Use Case Diagrams

Jesús Gallardo

, Ana Isabel Molina

, Crescencio Bravo

and Fernando Gallego

Escuela Universitaria Politécnica de Teruel, Universidad de Zaragoza, Ciudad Escolar, s/n, Teruel, Spain

Escuela Superior de Infomática, Universidad de Castilla-La Mancha, Paseo Universidad, 4, Ciudad Real, Spain

Keywords: Use Cases, Groupware, Collaborative Modeling, Empirical Study.

Abstract: Over the past few years, a great deal of work has been done in the field of collaborative software

(groupware). Many fields of science have taken advantage of these developments, and Software

Engineering is one such field. Within this scope, we have developed a domain independent synchronous

collaborative tool that can be specialized to work with several types of diagrammatical domains. Among

those domains, the diagrams used in the Unified Process can be found. In this paper we describe how we

have specialized this tool to work with use case diagrams and how we have carried out an empirical study

with this tool to obtain conclusions regarding several issues: the analysis of three kinds of communication

among users, the relationship between types of communication and coordination among users, and the

relationship between communication and the quality of the modeling work.

1 INTRODUCTION

Currently, many fields in industry, research and

education are taking advantage of the advances in

collaborative software applications and systems.

These applications have been classified in the so-

called field of groupware (Guareis de Farias, 2002).

Groupware is defined as those computer-based

systems that give support to a group of people who

work together on a shared task, and that provide an

interface to a shared environment (Ellis et al., 1991).

By means of computer networks and groupware

systems, shared workspaces are created and group

tasks of several kinds can be carried out.

Software Engineering is one of the fields that can

take advantage of the boom in the groupware area.

Specifically, many processes within the Unified

Software Development Process require the

participation of several actors with different or equal

roles. Thus, such actors may create or modify the

diagrams integrated in the Unified Modeling

Language (UML) in a collaborative way. This leads

us to the fact that a collaborative or groupware tool

can assist in the development of such work and

allow higher quality diagrams to be developed.

Another way in which groupware contributes to

Software Engineering is collaborative programming,

in which several programmers work on the same

source code when solving problems (Bravo et al.,

2013).

In this work, we focus in particular on the use

case diagrams used during the Requirements

Analysis phase. Within the tools that may support

this activity, we have decided to work with

synchronous collaborative tools. By means of these

tools, several users who are physically separated are

able to work on the same diagram at the same time.

This is also known as real time collaboration in the

literature. As explained in Section 2, the

synchronous collaborative building of such diagrams

using groupware tools is an area in which there is a

lack of relevant works. In synchronous collaborative

settings, participants are usually grouped in work

sessions in which they work together on a given

goal. In order to help the collaborative work be

done, these tools should integrate several widgets or

components for the support of communication and

coordination among the members of the

collaborative work session. Communication among

the participants in a collaborative work session is a

basic issue to be considered when carrying out the

Gallardo J., Molina A., Bravo C. and Gallego F..

A System for Collaborative Building of Use Case Models: Communication Analysis and Experiences - Experiences of Use and Lessons Learned from

the Use of the SPACE-DESIGN Tool in the Domain of Use Case Diagrams.

DOI: 10.5220/0004888800590068

In Proceedings of the 9th International Conference on Evaluation of Novel Approaches to Software Engineering (ENASE-2014), pages 59-68

ISBN: 978-989-758-030-7

 2014 SCITEPRESS (Science and Technology Publications, Lda.)

tasks, as it is the most immediate way in which users

can coordinate their work and solve possible

situations of conflict that may arise during the

session. In this work, we have focused our interest

on analyzing the communication among users in a

collaborative work session. As mentioned, the work

to be analyzed is the synchronous collaborative use

case modeling.

In order to analyze a group of users’ behavior

regarding communication issues, an empirical study

is presented. We have analyzed the development of a

collaborative work task in the domain of use case

diagrams. This task has been carried out by using a

synchronous collaborative tool. Thus, our goals in

this study have been, on the one hand, to prove that

the development of use case diagrams in a

synchronous collaborative way by using a

groupware tool is feasible, and, on the other hand, to

analyze how the different possibilities of

communication and coordination users were

provided with have an effect on the process and also

on the results of the work. In this sense, we have

studied the results obtained during the work together

with the actions of communication and collaboration

performed by the members of the work sessions. The

task carried out by the participants in the study is the

building of a use case diagram starting from a

requirements specification in natural language.

In order to conduct this study, a synchronous

groupware tool that gives support to design and

modeling in a specific domain is needed. The tool

we have chosen to give support to our study is

SPACE-DESIGN (Duque et al., 2008). SPACE-

DESIGN is a domain independent synchronous

groupware tool that can be specialized to a wide set

of application domains by means of a simple process

of configuration. In this case, we have configured

the tool to support the development of use case

diagrams.

The remaining part of this work is organized as

follows: in Section 2, we deal with some systems

and approaches related to the work described in this

paper. Then, the SPACE-DESIGN collaborative tool

is described. In Section 4, we explain the empirical

study we have carried out in detail and we discuss

the results obtained. Lastly, we present some

conclusions and future work.

2 RELATED WORK

In this section, we tackle systems and technologies

related to the work completed. Firstly, in Subsection

2.1 we discuss those tools that support synchronous

collaborative modeling in any domain. Afterwards,

in Subsection 2.2 we mention some tools that are

used for the development of use case diagrams.

2.1 Tools for Synchronous

Collaborative Modeling

A few tools that support the synchronous

collaborative modeling of diagrams and artifacts in

several application domains exist. Some of them are

specific of a given domain and some others are

generic or domain independent, with this meaning

that they can be adapted to work on different

domains by means of a configuration process.

Some examples of domain independent

collaborative modeling tools are Cool Modes and

Synergo. Cool Modes (Pinkwart et al., 2001) is a

cooperative modeling system that contains a

workspace including a set of plug-ins. These plug-

ins are actually palettes that contain the objects that

can be placed over the shared workspace and the

links to create relationships between the objects. In

Cool Modes it is not possible for users to

reconfigure or extend the functionality of the tool by

adding new palettes that support new application

domains. Synergo (Avouris et al., 2004) is also a

tool for the design on a shared whiteboard. Synergo

contains a predefined set of objects that can be

placed on that whiteboard. This set cannot be

extended. Another feature included in Synergo is a

powerful communication system in the form of a

chat for the discussion among the members of the

work session. This chat includes the possibility of

sending predefined messages that can direct the

communication. Such messages usually deal with

making proposals and accepting or denying them.

Thus, Synergo introduces the concept of structured

chat, about which we will talk later.

SPACE-DESIGN (Duque et al., 2008) is a

synchronous collaborative modeling tool. It is

reconfigurable and extensible. In order to configure

it for a specific application domain, XML-based

files are used. This tool includes some widgets for

awareness and coordination support, which are

implemented as reusable components. One of those

widgets is a structured chat, as explained in Section

3. The presence of the chat is one of the main

reasons for the selection of this tool for the empirical

study. The usefulness of chats and similar

communication mechanisms has been proved in

diverse collaborative tasks (Lund et al., 1996), and

specifically in requirements elicitation in software

engineering (Calefato et al., 2012). In fact, we have

used SPACE-DESIGN in our research group for

ENASE2014-9thInternationalConferenceonEvaluationofNovelSoftwareApproachestoSoftwareEngineering

other works in which we have needed a synchronous

collaborative tool (Gallardo et al., 2011). Of course,

we have specialized SPACE-DESIGN in order to

make it work over the use case diagrams domain.

Other systems, such as the aforementioned Cool

Modes and Synergo, could not have been configured

in such a way. Further explanations about SPACE-

DESIGN can be found in Section 3.

Now, we go back to the concept of structured

chat. The usual way to support communication in

synchronous collaborative tools is to include a chat

that allows users to communicate to each other. The

use of a chat is especially important in tasks such as

creating artifacts or diagrams on a synchronous way,

as it allows communication during the work

sessions. A special kind of chat is the structured

chat, in which users can use specific sentence

openers that are used to have a more directed

conversation. Usually, sentence openers are related

to the specific domain of the tool.

Synergo and SPACE-DESIGN are examples of

tools that include a structured chat. Another one is

COLER (Constantino-González et al., 2001). This

system is a web based collaborative environment for

the learning of Entity-Relationship diagrams. Some

other interesting tools that use structured

communication are C-CHENE (Baker & Lund,

1996), which deals with the building of energy

chains, and EPSILON (Soller & Lesgold, 2000), for

object-oriented design with OMT diagrams.

2.2 Collaborative Tools for the

Development of Use Case Diagrams

There exist several tools for the development of use

case diagrams, both collaborative and non-

collaborative ones. In the scope of our institution,

Rational Rose and Visual Paradigm are the ones that

have been used in the recent times, both of them

being non-collaborative tools. Next, we are going to

talk about some collaborative tools that have been

developed in the scientific and commercial spheres.

In (Fuenzalida and Antillanca, 2010) two tools

for the textual edition of use cases are described and

compared. One of these tools is synchronous,

whereas the other one is an asynchronous tool.

Neither tool handles diagrams, but they allow the

textual edition of the use cases and the relationships

among them. The comparison between the tools is

done by calculating some metrics. Most metrics give

best values to the asynchronous tool, but the

synchronous modeling seems to have some relevant

advantages. For instance, it takes less time to obtain

the final model.

Most existing systems that implement some kind

of collaboration to edit use cases or to build use case

diagrams actually implement an asynchronous

collaboration. Even this collaboration is sometimes

just a mere management of group work or a kind of

version control system. Some tools implementing

such approaches are CaseComplete (Serlio Software,

2013) or Visual Use Case (TechnoSolutions Corp.

2013). Another category is that of those tools that

deal with software lifecycle in a wider sense and

contain specific components for the management of

use cases. This is the case of the Rommana system

(Rommana Software, 2013). This tool includes

requirements management, tests management and so

on, together with a use cases management unit.

Thus, we can conclude that synchronous

collaborative use cases modeling is a field that has

not been explored enough and that can provide some

advantages when carrying out the modeling tasks. In

the same way, we understand that it is interesting to

analyze the communication and coordination of the

teams of analysts or engineers that perform the

collaborative modeling, so that we can obtain some

conclusions to improve the process. In the following

section, the SPACE-DESIGN tool is described in

detail. SPACE-DESIGN is the tool used to carry out

the collaborative use case diagrams modeling in the

empirical study described in Section 4. As

mentioned in Section 2.1, this tool has been chosen

because it presents some features that make it more

suitable than other tools.

3 THE SPACE-DESIGN TOOL

The SPACE-DESIGN tool (Figure 1) is a system

that is the instrumental part of a methodological

approach for the model-driven development of

collaborative modeling systems (Gallardo et al.,

2011b). In particular, SPACE-DESIGN supports

distributed synchronous work, allowing users to

build models collaboratively. It is domain-

independent since the system processes the domain

specification, expressed by means of an XML-based

language, and spawns the user interface and the

necessary functionality to support that specific type

of modeling, including specific interaction and

awareness design aspects in the groupware user

interface.

As shown in Figure 1, SPACE-DESIGN has a

shared whiteboard (A) where users can work with

the different elements that make up the application

domain. These elements can be one of two types:

objects (B) and relationships (C). Both types are

ASystemforCollaborativeBuildingofUseCaseModels:CommunicationAnalysisandExperiences-ExperiencesofUse

andLessonsLearnedfromtheUseoftheSPACE-DESIGNToolintheDomainofUseCaseDiagrams

instantiated from the toolbars that are located on the

left-hand side of the user interface (D, E). These

toolbars will vary according to the domain in which

the system is working, and the objects and

relationships will be those that appear in the domain

specification.

Figure 1: The SPACE-DESIGN tool working with the

domain of digital circuits.

An important characteristic of SPACE-DESIGN

are the elements for awareness (Dourish and

Bellotti, 1992) and collaboration support that are

included by default. These elements are: a session

panel that shows the users who is participating in the

design session and identifies them by means of a

specific color (F), the identification of the elements

that users select by means of colors, the telepointers

that indicate where the other users are pointing to

(G), a structured chat feature for communication

between the participants (H), and a list of

interactions indicating what actions have taken place

and who has carried them out (I).

The presence of these awareness and

collaboration support elements is one of the features

that make SPACE-DESIGN different from other

similar systems, such as Synergo or CoolModes.

However, the main differences between SPACE-

DESIGN and these systems are that, while the

former adapts itself in a flexible way to new

domains, incorporates awareness mechanisms, and

stores the developed models in XML files (Figure

2), the other systems have difficulty incorporating

new domains, have fewer awareness mechanisms

and, in the case of CoolModes, store the models in a

proprietary format (Gallardo et al., 2008).

Concerning the supported domains, the

aforementioned systems allow for the modeling of

several domains from a series of specifications

programmed in the system itself, whereas SPACE-

DESIGN defines the domains in a way that is

external to the system, by means of specifications

that can be built by end users. This means that any

domain made up of objects and relationships

between them, and actions to manipulate them can

be modeled in this way, and as such, SPACE-

DESIGN can be used to work with this domain in a

collaborative way. Specifically, in this work, starting

from the use cases domain specification, SPACE-

DESIGN adapts its user interface to give support to

use case diagram modeling.

Figure 2: Excerpt from the specification of the use cases

domain and its translation to the user interface.

SPACE-DESIGN has already been tested with

domains such as digital circuits, conceptual maps,

Bayesian networks, etc. (Duque et al.,

2008).Regarding the work described in this paper,

this differs from previous ones on this tool in the

application domain chosen, in the fact that we have

carried out an empirical study, not just a heuristic

analysis, and in the focus on the analysis of

communication mechanisms.

Next, we are going to detail the possibilities of

communication (that is, the communication

mechanisms) that SPACE-DESIGN is provided

with.

3.1 Communication Features of

SPACE-DESIGN

As stated before, communication is a very important

issue when performing collaborative tasks,

especially in real time working environments; the

most usual communication mechanism is the

exchange of textual messages. SPACE-DESIGN

supports three types of synchronous textual

communication as follows:

 Free Communication. With this name, we are

ENASE2014-9thInternationalConferenceonEvaluationofNovelSoftwareApproachestoSoftwareEngineering

referring to the kind of communication that

happens in traditional chats. That is,

communication that is based on the free

exchange of textual messages among the

members of the work team. No constraints are

defined in this sense.

 Communication with References to Objects.

Regarding collaborative modeling, in addition to

traditional free talk, it is possible to enrich the

conversation with some references to the domain

objects in the collaborative task in which the

work is being done. The different domain objects

(actors and use cases in the domain of use case

diagrams) that can be placed in the shared

context can be selected and included in the

conversation. It is assumed that including

references to domain objects favors group and

task awareness, as it allows guiding and

centering the conversation on certain elements

from the shared model.

Figure 3: The structured chat with references to objects

included in SPACE-DESIGN.

 Structured Chat. This kind of chat provides

users with a set of predefined messages with

which the user can show the kind of contribution

or message, as well as its intention. Thus, the

organization of the talk is favored. The

categories of the messages can be defined

according to the particular needs of the

collaborative task to support and to the specific

domain in which work is being done. Moreover,

this technique allows reusing structures from

previous conversations, as the text of the

messages is often a sentence, opinion or

comment that is used during the task on a regular

basis. In the case of SPACE-DESIGN, messages

have been classified regarding their type

(statement, question or answer) and their position

in the conversation (some of them are

conversation starters, such as “Why…” and

others are reactive ones, such as “Because…”).

Table 1 depicts the generic sentence openers in

SPACE-DESIGN. In this kind of chat, references

to objects are also possible. In fact, SPACE-

DESIGN offers the possibility to have a

structured chat with references to objects, as is

shown in Figure 3.

Table 1: Sentence openers in SPACE-DESIGN.

Sentence opener Type Position in the

conversation

I think that… Statement Conversation starter

Why… Question Conversation starter

I miss a… Statement Conversation starter

There’s a mistake in… Statement Conversation starter

I think so Statement Reactive

I don’t think so Statement Reactive

I don’t know Answer Reactive

Because… Answer Reactive

4 EMPIRICAL STUDY

In this section, we describe in depth the empirical

study carried out to evaluate the different

possibilities of synchronous communication that

SPACE-DESIGN is provided with. We have

considered it interesting to analyze how users

collaborate using the different communication

mechanisms, and how such mechanisms have an

influence on the work performed and the results

obtained. In this sense, we have tested the three

kinds of chat in SPACE-DESIGN. We have tried to

state whether there is an influence of the kind of chat

on the work carried out. In addition, we have an

interest in knowing the subjective perception users

have regarding the usefulness of the mechanisms, as

well as their preference for one or another kind of

communication. Regarding communication issues,

we have also asked users for their preference

between the three kinds of chats.

Thus, the research questions we contemplate in

this scenario are the following:

 Does the choice of a certain communication

mechanism have an influence on the fluency of

the communication?

 Does the communication mechanism have an

influence on coordination?

 What relationship between the communication

mechanism and the quality of the use cases

models exists?

4.1 Participants

A total number of 28 students of the Escuela

Superior de Informática in the University of

Castilla-La Mancha (Spain) took part in the study

voluntarily. All of them were taking a course on

Software Engineering in the third year of a

Computer Science degree.

ASystemforCollaborativeBuildingofUseCaseModels:CommunicationAnalysisandExperiences-ExperiencesofUse

andLessonsLearnedfromtheUseoftheSPACE-DESIGNToolintheDomainofUseCaseDiagrams

4.2 Experimental Task

The collaborative task to be carried out by the

participants consisted in building a use case diagram

making use of the SPACE-DESIGN collaborative

tool. Students were given a textual specification of

the problem to be solved, which was of an

intermediate difficulty. Two different problems were

proposed, so not all the groups solved the same

problem. Specifically, the problems were: (P1) the

modeling of the system of a tour operator that had to

manage trips and travelers, and (P2) the modeling of

the system of a harbor, which had to deal with the

management of ships, the arrival of boats, etc.

Figure 4 shows a screenshot obtained during the

study. In the figure, the work done by a group of

participants that had to solve P2 can be seen. The

screenshot corresponds to a user who is not editing

the diagram. The tele-pointer of the user who is

editing can be partially seen in the bottom of the

diagram. The last messages exchanged by the users

can be seen in the chat.

Figure 4: Screenshot of the use of SPACE-DESIGN

during the empirical study.

4.3 Experimental Design

For the design of this empirical study, several steps

were followed. Firstly, the students who were to take

part in it attended a seminar about the SPACE-

DESIGN tool. There, students could try out the tool

and learn how it works, which features it includes

and what it can be used for.

Then, the 28 participants were divided into two

groups of 10 members and one group of 8 members.

Two groups worked on problem P1, whereas the

remaining group worked on problem P2. Participants

in each group were then grouped in pairs whose

participants were physically separated while

carrying out the study. Each group was randomly

assigned a different communication mechanism.

Thus, 4 pairs (8 participants) used the traditional

chat, 5 pairs (10 participants) used the chat with

references to objects, and 5 pairs (10 participants)

used the structured chat.

During the problem solving, in which the

modeling task was carried out, participants were

allowed to look up the help manual of the tool, as

well as the formulation of the problem to be solved.

Each participant was provided with a unique user

name and password so that they could use the tool

and access the work session they should join. The

structure of sessions and groups is depicted in Table

Table 2: Structure of sessions and groups in the empirical

study.

Problem Chat Participants Groups

Chat with reference

to objects

P1 Traditional chat 10 1

Structured chat 2

Chat with reference

to objects

P2 Traditional chat 8 2

Structured chat 1

Chat with reference

to objects

P1 Traditional chat 10 1

Structured chat 2

Once the task was completed, the participants in

the study went to fill out a test made up of 10

questions with a five-point Likert scale format. This

test allowed users to evaluate the usefulness of the

tools, as well as of the different communication

mechanisms included in it. The test also included a

section for additional remarks, in which participants

could express their opinion or make suggestions for

the improvement of the tool and the study.

This empirical testing was designed with the aim

to lighten some threats to internal and external

validity. For example, each group was randomly

assigned a different communication mechanism. In

addition, the universe of discourse of the problem to

be solved was well known by the participants.

Regarding fatigue effects, the average time spent in

completing the designing tasks was approximately

60 minutes. Hence, we consider that fatigue did not

have an influence on the result obtained. In relation

to subject motivation, we have to mention that

subjects were highly committed to this research. In

relation to external validity, one issue that could

affect the validity of the conclusions of this study is

the size of the sample data. We are aware of this, so

ENASE2014-9thInternationalConferenceonEvaluationofNovelSoftwareApproachestoSoftwareEngineering

we will consider carrying out replications of this

study with a larger sample size. Other issue to

analyze is the sample nature. In order to guarantee

the external validation of empirical studies, it is

recommendable to recruit representative

participants. Because of the difficulty of obtaining

professional subjects, we used undergraduate

students from a software engineering course. This

fact threatens the validity of conclusions and

external validity. However, if we consider that

students can be considered future professionals and

had enough capacity to participate in this task, these

experimental subjects can be considered appropriate.

4.4 Results and Discussion

In this section, we are going to show the results of

the empirical study, discuss them and state the

conclusions that have been drawn from them. We

have divided this discussion into three subsections:

the first one is about a descriptive analysis of the

data collected, in the second one, we study the

possible correlations between the data, and in the

third one, we deal with the results of the subjective

opinion of the participants about their experience.

4.4.1 Descriptive Analysis

We are going to start by talking about the metrics we

have calculated for the groups taking part in the

study. Firstly, we are going to consider the amount

of information exchanged by the groups, which we

have measured by means of the number of messages

exchanged, the average number of words per

message and the total number of words exchanged.

In these three metrics, when grouping the values

considering the kind of chat, the chat with references

to objects obtained better values (Table 3).

In addition to this analysis of the amount of

information exchanged, we have also analyzed the

content of the messages and their nature. From these

data, we calculated the number and percentage of

interrogative messages as well as the number of

domain dependent words exchanged between the

members of the group (see Table 3). We classify

domain dependent words as those that refer to use

case diagrams (“use”, “case”, “actor”, “extends”,

etc.) as well as those which are specific to the

problem formulation. Examples of relevant words

are “room” or “lodging” in P1 and “boat” or “dock”

in P2 (actually, the words in Spanish with those

meanings). In this sense, the values were again

higher when calculating the totals and averages for

the chat with references to objects. Thus, we can

state that the communication was more fluent in the

groups working with that kind of chat.

Table 3: Statistics on messages and words communicated

during the study. Each cell includes the mean value (M)

and, in parentheses, the standard deviation (SD).

Traditional

chat

Chat with

references

to objects

Structured

chat

Total number of

messages per

group

104.25 (45.26)

151.40

(48.86)

98.60 (48.94)

Average

number of

words per

message

5.10 (0.91)

5.98 (1.33)

5.06 (0.55)

Total number of

words

61.25 (33.89)

106.00

(24.38)

70.40 (46.26)

Number of

interrogative

messages

16.50 (13.08)

24.40 (5.46)

12.60 (6.88)

Percentage of

interrogative

messages

14.39 (6.93)

18.72 (11.24)

12.73 (5.12)

Number of

domain

dependent

words

51.25 (31.08)

76.60 (20.68)

53.60 (38.89)

Regarding coordination needs, we measured the

number of turn changes accomplished by each

group. Groups using the traditional chat obtained

higher values (M=7.25; SD=2.06), whereas groups

with the chat with references to objects received

smaller values (M=5.80; SD=1.92).

Taking into account all the data collected up to

this point, we can conclude that the possibility of

including references to domain objects seems to

cause the users to focus on the conversation and

make longer contributions, which are centered on

the problem to be solved. In addition, it seems that

with this chat it is less necessary to move the

conversation between the members of the group. At

the very least, we have detected fewer turn changes

than in other cases.

Next, we are going to match these results with

the performance of the groups when solving the

modeling problem. The teacher evaluated the models

developed during the study by giving each one a

grade on the solution given to the problem. The

grade was later divided into two separate grades

regarding use cases and relationships. All these

grades were calculated with 0 as the lowest and 10

the highest value. In this sense, again those that

made use of the chat with references to objects

obtained better grades (M=6.21; SD=1.35), whereas

those who used the structured chat obtained the

worst ones (M=4.31; SD=2.21). To check whether

these results were influenced by the previous

ASystemforCollaborativeBuildingofUseCaseModels:CommunicationAnalysisandExperiences-ExperiencesofUse

andLessonsLearnedfromtheUseoftheSPACE-DESIGNToolintheDomainofUseCaseDiagrams

knowledge of the participants, their teacher was

asked about the previous grades they had obtained

in the course. Taking all of this into account, it was

discovered that some groups were made up by

students with similar previous grades (homogeneous

groups), whereas some other groups consisted of

two students with significant differences in their

previous grades (heterogeneous groups). As we did

not intentionally arrange the groups in this way, it is

difficult to draw definitive conclusions about how

this difference affected the other variables being

analyzed. Thus, in future studies we will study the

influence of the distribution in homogeneous and

heterogeneous groups on the performance.

4.4.2 Correlation Analysis

In addition to the descriptive analysis of the data

collected, we also carried out a correlation analysis

between the variables. Next, we are going to discuss

the main correlations that appeared. The first

correlation we detected was that those groups whose

members had higher previous grades used more

domain dependent words when using the chat

(r=0.60; p=0.05). It can be deduced from this

correlation that those groups whose members

performed better in the course were more focused on

carrying out the activity. In addition, these groups

were those that exchanged a higher number of

messages (r=0.64; p=0.05). The correlation with the

number of interrogative messages was also positive

(r=0.69; p=0.05).

On the other hand, a negative correlation (r=-

0.57; p=0.05) was detected between the number of

turn changes and the number of exchanged words.

This makes us think of two styles of working

between the members of the group: a style in which

one of the two members is working most of the time

and the collaboration is made by means of the chat,

and a second style in which members make less use

of the chat and prefer to frequently change turns.

Lastly, it is worth noting a correlation that is not

related to communication issues, but is specific to

the domain of use case diagrams. Specifically, a

positive correlation between the size of the model

and the grade given by the teacher to the model

regarding the suitability of the use cases chosen was

detected (r=0.69; p=0.05). From this correlation, we

can infer that, in those cases in which users did not

select the proper set of use cases, the usual situation

was that they used fewer uses cases than the amount

included in the solution of the problem, and not the

inverse situation in which they had used too many

use cases.

4.4.3 Subjective Opinion Analysis

To finish with the analysis of the study, we are going

to talk about the results related to the subjective

perception of the participants concerning the use of

the tool and its communication mechanisms. In

order to collect the information, participants filled

out a test made up of some questions with a Likert

scale (1 to 5). Some questions were meant to find

out the opinion of the participants about the

usefulness of SPACE-DESIGN for the collaborative

modeling of use case diagrams. Participants gave a

mean value of 3.6 (SD=0.4) to that variable. This led

us to think that users expressed their interest for the

use of a collaborative tool such as SPACE-DESIGN

for the collaborative design of use case diagrams.

Thus, we could state that users would choose

SPACE-DESIGN or a similar tool when willing to

carry out such collaborative tasks instead of using

single user tools shared by means of any software

mechanism. This is a preference we have found in

previous works (Gallardo et al., 2011).

In addition, the test contained some questions

about the preference of the participants on the

different communication mechanisms. In this sense,

most users preferred the traditional chat, being the

chat with references to objects the second one most

valued and the structured chat the one which was

least valued by the participants. However, in the

case of these two kinds of chat, the possibility of

referring domain objects during the conversations

was given high values (M=3.4; SD=0.34).

5 CONCLUSIONS AND FUTURE

WORK

In this paper, we have started by introducing a

synchronous collaborative tool that can be

specialized to work with several modeling domains.

In this case, we have specialized the tool to make it

work with use case diagrams, and we have used it to

do an empirical study so that we can draw some

conclusions about how users carry out collaborative

tasks and how communication during the work

sessions has an influence on the process and the

results of the work.

The study carried out is preliminary, and will be

followed by some other studies with more users and

tasks that are more complex. Nevertheless, we have

drawn some interesting initial conclusions about the

variables being studied. For example, regarding

communication issues and previous grades of the

participants, we have observed how users with a

ENASE2014-9thInternationalConferenceonEvaluationofNovelSoftwareApproachestoSoftwareEngineering

higher knowledge level have communicated to each

other more. Specifically, they have also exchanged

more domain specific messages, so they have

focused more on the task to perform. In the same

way, it has been possible to identify a difference

between two potential styles of collaborative work:

one in which collaboration occurs at a

communication level, and another in which there are

frequent turn changes. Regarding domain specific

conclusions, the most relevant one was that when

users had problems defining the suitable set of use

cases, these problems came from a lack of use cases,

and not an excess of them.

Another conclusion we have drawn is that users

do not find different versions of advanced chats we

have implemented useful. Instead, they prefer to use

the traditional chat. This can be seen in the statistics

of use of the chats as well as in the subjective

evaluation carried out by users. Regarding statistics

obtained during the study, users working with the

chat with references to objects exchanged more

messages, changed turns less often and obtained

higher grades. We have concluded that users

working with this chat seem to focus on the

conversation about the problem to be solved.

However, a traditional chat do not cause this effect

and causes users to change turns very often.

Concerning recommendations for the further use of

chats in this kind of tools, the study make us think

that the traditional chat is the best option as long as

the advanced chats do not include features that make

them attractive enough for users. A better ease of

use or some adaptable options may help to achieve

this goal.

To conclude with, it will be necessary in further

empirical studies to analyze the reasons behind the

preference for the traditional chat. The uselessness

of advanced chats for a certain domain and an

incorrect implementation of the concepts

incorporated in the tool are some possible reasons

that will have to be considered. For example, a

different set of sentence openers in the structured

chat may have yielded higher values. In general,

results obtained during the study may have been

influenced by the amount of users that participated

and for the nature of the problems that users solved.

Thus, in further studies we will try to count on the

presence of a higher number and more representative

sample of users and we will use a different kind of

problems in order to check whether the results of

this study are validated or not.

ACKNOWLEDGEMENTS

This research has been partially supported by the

Ministerio de Economía y Competitividad (Spain) in

the TIN2011-29542-C02-02 project.

REFERENCES

Avouris N., Margaritis, M., Komis V., 2004. Modelling

interaction during small-groups synchronous problem-

solving activities: The Synergo approach. In:

Proceedings of the 2nd International Workshop on

Designing Computational Models of Collaborative

Learning Interaction, pp. 13-18.

Bravo, C., Duque, R., Gallardo, J., 2013. A groupware

system to support collaborative programming: Design

and experiences. Journal of Systems and Software 86

(7), pp. 1759-1771.

Calefato, F., Damian, D., Lanubile, F., 2012. Computer-

mediated communication to support distributed

requirements elicitations and negotations tasks.

Empirical Software Engineering 17 (6), pp. 640-674.

Constantino-González, M., Suthers, D., 2001. Coaching

Web-based Collaborative Learning based on Problem

Solution Differences and Participation. In: Moore,

J.D., Redfield, C.L., Lewis Johnson, W. (eds.)

Proceedings of the Int. Conf. AI-ED 2001: p. 176–187.

Dourish, P., Bellotti, V., 1992. Awareness and

Coordination in Shared Workspaces. In: Proceedings

of the Conference on Computer Supported

Cooperative Work CSCW'92, pp. 107-114.

Duque, R., Gallardo, J., Bravo, C., Mendes. A. J. , 2008.

Defining tasks, domains and conversational acts in

CSCW systems: the SPACE-DESIGN case study.

Journal of Universal Computer Science 14 (9), pp.

1463-1479.

Ellis, C.A., Gibbs, S.J., Rein, G, 1991. Groupware: some

issues and experiences. Communications of ACM.

34(1).

Fuenzalida, C.M., Antillanca, H.B., 2010. Synchronous

versus Asynchronous interaction between users of two

collaborative tools for the production of Use Cases. In

CLEI Electronic Journal 13 (1).

Gallardo, J., Bravo, C., Redondo, M.A., 2008. Developing

collaborative modeling systems following a model-

driven engineering approach. In: On the Move to

Meaningful Internet Systems: OTM 2008 Workshops,

Lecture Notes in Computer Science 5333, pp. 442-451.

Gallardo, J., Molina, A.I., Bravo, C., Redondo, M.A.,

Collazos, C., 2011. Empirical and heuristic-based

evaluation of collaborate modeling systems: An

evaluation framework. Group Decision and

Negotiation 20 (5).

Gallardo, J., Molina, A.I., Bravo, C., Redondo, M.A.,

Collazos, C., 2011b. An ontological conceptualization

approach for awareness in domain-independent

collaborative modeling systems: Application to a

model-driven development method. Expert Systems

ASystemforCollaborativeBuildingofUseCaseModels:CommunicationAnalysisandExperiences-ExperiencesofUse

andLessonsLearnedfromtheUseoftheSPACE-DESIGNToolintheDomainofUseCaseDiagrams

With Applications 38 (2), pp. 1099-1118.

Guareis de Farias, C.R., 2002. Architectural Design of

Groupware Systems: a Component-Based Approach.

Ph.D. Thesis.

Lund, K., Baker, M.J., Baron, M., 1996. Modelling

Dialogue and Beliefs as a Basis for Generating

Guidance in a CSCL Environment, In: Proceedings of

the International Conference on Intelligent Tutoring

Systems, pp. 206-214

Pinkwart, N., Hoope, U., Gassner, K., 2001. Integration of

Domain-Specific Elements into Visual Language

Based Collaborative Environments. In Proceedings of

the Seventh International Workshop on Groupware,

IEEE Computer Society.

Rommana Software, www.rommanasoftware.com, visited

July 24

2013.

Serlio Software, www.casecomplete.com, visited July 24

2013.

Soller, A., Lesgold, A., 2000. Knowledge acquisition for

adaptive collaborative learning environments, In:

Proceedings of the AAAI Fall Symposium: Learning

How to Do Things, Cape Cod, MA.

TechnoSolutions Corporation, www.visualusecase.com,

visited July 24

2013.

ENASE2014-9thInternationalConferenceonEvaluationofNovelSoftwareApproachestoSoftwareEngineering