Michel Dirix
email: michel.dirix@axellience.com

Awareness in Computer-Supported Collaborative Modelling. Application to GenMyModel

Keywords: Collaboration, Awareness, UML

Costs and markets lead engineering teams to collaborate from different location all over the world. Modelling tools are present in development processes to produce complex software and these tools had to be highly collaborative to permit teams to be productive. For that, teams need information about others and their activities. Currently, the tools are mainly web-based, this is the observed trend in every phase of software development, because it does not require any installation and configuration, but they do not give enough information. This paper will present awareness, which is an answer to the information needed during collaboration, and through a scenario we will see how to answer to awareness questions in UML Case Tools.

Introduction

Since a decade, outsourcing and offshoring projects or part of them have become regular practices in software industry. These ones can have different reasons like the need to cut down costs or to explore new markets. Collaboration between project team members suffers from resulting geographical distribution. First, such situations involve language, cultural and timezone differences. Second, in co-located settings, information is shared by personal interruptions (popping into a colleague office or meeting over coffee), formal face to face meetings, emails, instant messaging. Collaboration is "natural" and each team member can easily find an answer to questions about it: who is participating to the activity? Where are they? Are they active in the workspace? What are they doing? What are they going to do? What changes are they making? [START_REF] Gutwin | Workspace awareness in real-time distributed groupware: Framework, widgets, and evaluation[END_REF]. The way to find the answers to the previous questions is far more difficult when dealing with geographical distributions.

The topic of my PhD thesis addresses the problem of modelling in distributed teams. Software practitioners usually draw diagrams when they design new applications, maintain existing ones or discuss with their clients using modelling tools [START_REF] Grossman | Does uml make the grade? insights from the software development community[END_REF]. Besides, models are important to manage knowledge and provide an efficient support to coordinate activities when the projects aims at producing complex software. It is important that modelling tools intent to support collaboration in the context of distributed teams, that is to say, to provide similar working conditions close to co-located settings. Collaborative modelling tools exist (see section 2) but they only focus on and provide basic communication features. They slightly address one of the main aspects of Computer-Support Cooperative Work (CSCW): awareness. Collaboration awareness is an issue that has been considerably studied by the CSCW community. It has been much less studied in software engineering. But as web-based tools currently appear in software projects (e.g. dashboard, code editor) and as they highlight real-time collaboration features, the general interest for collaboration awareness is likely to increase. The goal of my PhD is to study problems related to Collaboration Awareness in collaborative modelling activities/tools, to propose solutions and to experiment them in order to validate them.

The remainder of the paper is organized as follows. In Section 2, we describe what collaboration awareness is and how it is currently handled by collaborative modelling tools. In section 3, we present a scenario that gives more details of what collaboration awareness is within such tools. The section 4 reports how we plan to experiment future results thanks to GenMyModel, a web-based collaborative modelling tool1 .

Awareness

Definitions

The most widely used definition of Awareness is given by Dourish and Bellotti [START_REF] Dourish | Awareness and coordination in shared workspaces[END_REF] : '... an understanding of the activities of others, which provides a context for your own activities'. Schlichter [START_REF] Schlichter | Awareness -the common link between groupware and community support systems[END_REF] insists few years later on this aspect of CSCW in order to reach and to maintain effective coordination of collaborative work. In his review of awareness in Distributed Collaborative Software Engineering [START_REF] Omoronyia | A review of awareness in distributed collaborative software engineering[END_REF], Omoronyia defines five types of awareness as follows:

-Workspace awareness : the up-to-minute knowledge of other participants interactions with the shared workspace [START_REF] Gutwin | Support for workspace awareness in educational groupware[END_REF]. -Informal awareness : the general sense of who is around, what they are doing, and what they are going to do [START_REF] Gutwin | Workspace awareness in real-time distributed groupware: Framework, widgets, and evaluation[END_REF]. -Group-Structural awareness : knowledge about people roles and responsibilities, their positions on an issue, their status, and group processes [START_REF] Gutwin | Workspace awareness in real-time distributed groupware: Framework, widgets, and evaluation[END_REF]. -Social awareness : Information about the presence and activities of people in a shared environment [START_REF] Prinz | Nessie: An awareness environment for cooperative settings[END_REF]. -Context awareness : The evolving internal and external state information that fully characterizes the situation of each entity in a shared environment [START_REF] Omoronyia | A review of awareness in distributed collaborative software engineering[END_REF].

These types refer to a series of questions people ask themselves when they collaborate. Table 1 draws a list of main ones. We illustrate some of these questions in the next section. At what times did the activity take place? x Activity Duration How long did the activity last? x Concurrent Activities What concurrent activities were entities involved in?

x *W : workspace, I : Informal, GS : Group-Structured, S : Social, C : Context Table 1. Awareness answers to collaboration raised questions based on [START_REF] Omoronyia | A review of awareness in distributed collaborative software engineering[END_REF] Workspace awareness is the most studied in awareness literature [START_REF] Omoronyia | A review of awareness in distributed collaborative software engineering[END_REF] and it seems to be also the most important type in Distributed Collaborative Software Engineering. Even if awareness is the focus of lot of scientific works for decades, it is still a scientific issue. The volume of April 2013 issue of Computer Supported Cooperative Work [START_REF] Kolfschoten | Differentiated awareness-support in computer supported collaborative work[END_REF] presents recent scientific results on awareness in different areas (distributed software development, model versioning, virtual team, social media...). Besides, new interesting direction of research relates to recent interactive technologies like large tactile surfaces. Yuill [START_REF] Yuill | Mechanisms for collaboration: A design and evaluation framework for multi-user interfaces[END_REF] reports case studies about awareness with such technologies. He points out that, for example, one of the originalities of multi-user interfaces is the presence of "mutual" awareness.

Whitehead shows that the trend concerning collaboration support is the arrival of web-based tools in every phase of software development [START_REF] Whitehead | Collaboration in software engineering: A roadmap[END_REF]. Their main advantage is that they do not require any installation or configuration: teams are quickly ready to work. So, my first investigations will mainly concern web-based tools. I will analyze desktop tools later.

In current Collaborative model editor

I have found two web-based tools, they deal with workspace awareness but do not cover other awareness type. In his work on GEMSjax (a meta-modelling tool) [START_REF] Farwick | A webbased collaborative metamodeling environment with secure remote model access[END_REF],

Farwick discuss briefly about awareness. He resumes it to a chat and events to see which elements are currently selected but without give more details. A chat should cover all awareness type in processing content and filtering discussion to have more informations. But it seems this is not the case for GEMSjax. Chat is only used to discuss. Thum with his work on SLIM [START_REF] Thum | Slima lightweight environment for synchronous collaborative modeling[END_REF] is akin to Farwick work from awareness point of view. SLIM is an UML Case Tool for synchrounous collaborative modelling based on a lock system to avoid conflicts. When a user click on an element, a lock is put in place to prevent modifications by another user. Concerning awareness, SLIM contains a chat to discuss (content is not processed), with messages and current connected users, and padlocks on model elements locked by other users as seen in figure 1. The two found tools focus on synchrounous collaboration but awareness is not enough involved. As I'm PhD student since January 2013, related works have to be more studied and perhaps I will have to study awareness in other collaboration tool types. For the moment, my first work is to see if workspace awareness is the only necessary awareness type needed for collaboration in modeling tools.

Illustration of awareness in collaborative modelling

In this section, we illustrate with an example of model (subsection 1) and a related scenario, what kind of information UML practitioners may need about the actions of their co-workers in order to efficiently collaborate when they all work along the same model (subsection 2). We align such information on questions that we have previously mentioned when defining awareness (subsection 3).

Scenario

The sketch in this paper is an e-shopping project as figure 2 shows. The associated model, named webcomm, is composed of several diagrams which represent the future website from different points of view: a use case diagram with general actions that a customer can do, a global class diagram for the application and a small class diagram which focuses on one functionality. The latter will be improved to put in place Order (We will suppose that this diagram is just created and will be refined). As we can see, class Order is shared between the two class diagrams.

Fig. 2. Diagrams for webcomm model

This model and its diagrams are shared among several persons through an hypothetical collaborative UML case tool. We have two teams where first one (Alice, Bob and Ted) is in France and the other one (Jiao and Cheng) is in China as seen in figure 3. This implies that there is a time difference of 7 hours. When it is 9am at Paris, it is 4pm at Shanghai, that means the temporal window of real-time collaboration between the two teams is reduced. But even reduced, it exists and team members have to take advantage of it.

Figure 3 also shows actions of Bob, Alice and Jiao. We describe them in the next subsection.

In action

First, Alice connects to the online model editor and opens webcomm model. She has in mind to do refactoring because, at last meeting, one of the discussed problems concerns some classes that becomes too big. So, she looks for diagram and last changes. She thinks that Order is a little bit big and may be reduced by dispatching shipTo into a new class Address. She wants to discuss with the main contributor of Order to know if the change she plans to do has sense. She analyses Order history to find this contributor. This is Jiao. So, Alice contacts her to discuss. Jiao approve Alice's idea. So, Alice applies changes about shipTo.

Meanwhile, Bob arrives at work. The goal of his current task is to create Graphical User Interfaces (GUI) for Order. So, he connects to the editor, and opens webcomm model. He looks for current changes and tasks to know if his work will impact others. He knows that Cheng and him use to work on the same concerns, and that Cheng usually does not like being disturbed by external changes. By looking the activities of the others, he sees that Cheng is working on Customer but does not have information about Alice and Jiao because they do not tell which activity they are working on. Thanks to instant messaging history, he knows that Alice and Jiao have discussed about Order. With changes history, he sees that Alice has made modifications on Order. He contacts her to have in-depth explanations. However, refinement that Alice has made has no impact for him because he just begins to build the GUI and then he only focuses on the main features of Order. But if Alice modifies this class in the future, he will be notified through a visual notification about likely impacts. So, after his quick investigation, he can begin to work.

Scenario and awareness

This scenario highlights the fact that awareness-support is required to work in good conditions: each collaborator need many information about tasks that his/her co-workers aims to fulfill, actions they performed (or ones they plan to) or who currently participate to modelling. An instant messaging is not sufficient. Table 2 shows actions of the scenario for which the model editor has to provide related information to users in order they are efficiently aware of the whole activity of their team. Scenario covers all awareness types but not all their refinements as seen in table 2. For uncovered refinements (extents, abilities, activity time & duration), we may easily foresee situations where they would be useful. For example, for extents and abilities, a client may have to give his/her feedback about model, so he/she can have a restricted access on certain parts with just the read and comment permission. For activity time and duration, we could considerate that each time a user performs a action, this one is associated with her/his current task.

Cognitive overload

Providing support for different types of awareness is a positive point for users to reach real-life collaboration. Nevertheless, displaying and streaming too much informations may cause them a cognitive overload [START_REF] Yuill | Mechanisms for collaboration: A design and evaluation framework for multi-user interfaces[END_REF]. Users should finally lose important information. So there are some display rules to define in order to avoid cognitive load. For example, the actions history may be filtered in different ways: hiding move actions (not always useful to understand model construction), grouping elementary actions in an more abstract one (maybe with pattern detection mechanism)...

Conclusion and Future Work

In this paper, we have seen that a software engineering project work could be a highly cooperative and distributed activity. Modelling tools are used during the development process in order to manage knowledge, coordinate activities, design a new application, maintain existing ones or discuss with their clients. To collaborate, engineers need information about others and their activities as identity, actions on model, intentions, changes. This information is related to awareness. Through literature, only few modelling tools support collaboration. Among them, only partial workspace awareness is supported while the scenario presented in the paper highlights that workspace awareness is not the only one required to provide a strong collaboration feature in UML case tools.

Axellience currently develops a such UML Case Tool named GenMyModel2 (see figure 4). GenMyModel is a web-based tool so it does not require any installation or configuration. It is planned to be an industrial product that will be able to support very large projects (in term of model elements and team size) with several innovative features (tablets or smart boards support, model transformation, code generation, round tripping...). Axellience has began to communicate about a beta-version of GenMyModel since January 2013, and there are already more than 1500 of users distributed in more than 90 countries although collaboration is missing. Some models already reach more than 50 classes elements and includes several hundreds of model elements. For GenMyModel users, collaboration is the most asked feature. They see it as a real advantage for a successful project. Thanks to this ecosystem and users needs, I will benefit from a realistic context where I will apply my validation process. This ecosystem is a strong side of my work.

Until now, I studied works about awareness in collaboration on tactile surfaces. From this study, I identified awareness types and needed information that seem to be required for collaboration in UML Case Tools. Then, I compared this information with those present in few UML web-based tools. For the next step, I must identify in the CSCW literature all scientific results which can be useful and mapped in our context. Then, a study will be realized on existing UML Case Tools (web-based and desktop). For each, I will observe if they have After the list of tools which support awareness is established, I will discuss with communities to discover the reasons why they use this tool, get the advantages and disadvantages of each and what are the collaboration features they need. From this information, we will work with our users in an agile-like mode to deliver them expected features according to their need. For that, we will do a proposal, build a sketch by an implementation and provide it to the users to get their feedback. To do so, we will give volunteer users a customizable environment with those features. Their actions will be tracked to highlight which information is really needed during collaboration. After that, they will be sent a survey based on identified observations in order to confirm or not the observations. From this result, we will do a new proposal according to the figure 5. This cycle with users should begin in October.

Fig. 1 .

 1 Fig. 1. SLIM awareness

Fig. 3 .

 3 Fig. 3. Scenario

Fig. 4 .

 4 Fig. 4. GenMyModel

Fig. 5 .

 5 Fig. 5. Methodology

Table 2 .

 2 Needed information for collaboration in modeling tools

	Action of scenario	Awareness Related element W I GS S C
	List of present users	Identity
	What users are doing	Location/Activity Level/Actions
	Prior modifications	Activity Level/Changes
	Current modifications	Location/Activity
		Level/Actions/Changes/Sphere of In-
		fluence
	Impact on elements	Location
	Impact visualization	Intentions/Objects/Sphere of Influence
	Project involvement	Activity Level
	On what is collaborator	Intentions
	working
	Discuss for organization
	History	Activity History/Concurrent Activities
	Task understanding, need	Availability
	discuss if available
	*W : workspace, I : Informal, GS : Group-Structured, S : Social, C : Context

www.genmymodel.com

www.genmymodel.com


Michel Dirix
email: michel.dirix@ed-univ-lille1.fr

Xavier Le Pallec
email: xavier.le-pallec@univ-lille1.fr

Alexis Muller
email: alexis.muller@genmymodel.com

Software Support Requirements for Awareness in Collaborative Modeling

Keywords: Modeling, Collaboration, Awareness, Survey

To address issues of traditional modeling tools (installation, model versioning and lack of model repositories), Axellience has developed the first online UML modeling tool. In GenMyModel's beta-phase, the most requested feature was collaboration. Supporting collaborative modeling involves addressing classical concerns of CSCW. These issues are usually classified through core dimensions like awareness and articulation work. We decided to focus our research on the most important dimension: awareness. Commercial modeling tools and research prototypes provide little support for awareness.To define the importance of awareness in modeling tools, we decided to study what awareness information is really required in collaborative modeling and to assess its importance according to articulation work types. To do this, we have implemented a basic collaboration system without constraint on articulation work. After a few months of use, we have identified three articulation work types present in more than 500 collaborative projects. This preliminary study allowed us to define awareness elements potentially needed for each articulation work type. As these elements are different for each articulation work type, we launched different surveys for each one of them. With these surveys, we have sorted awareness information by relevance according to articulation work types.

Introduction

When a person uses a modeling tool, one problem is remembering where models are saved. Furthermore, installing a modeling tool can be time-consuming. When collaborators want to send models between them, they have to ensure that collaborators use the same version of the modeling tool. GenMyModel is an answer to these problems. GenMyModel 1 is an online modeling tool. As it is online, users do not have to install or update the modeling tool. In addition, they do not have to know where their models are saved. While GenMyModel was in beta-phase and had only 200 users registered, collaboration was the most requested feature. It was not planned at the beginning of GenMyModel's development to provide collaboration so quickly. We started by adding a basic version of collaboration. As of mid-May, GenMyModel had more than 50,000 users distributed in 200 countries, and more than 5,800 users were involved in more than 3,400 collaboratives projects. Collaboration is widely used and confirms the need of real-time collaboration as requested when GenMyModel had 200 users. Collaboration is above all being aware of others' activities. It implies displaying information about these activities. Thus, supporting collaborative modeling involves addressing classical concerns of CSCW(Computer-Supported Cooperative Work). "CSCW should be conceived as an endeavour to understand the nature and characteristics of cooperative work with the objective of designing adequate computer-based technologies" [START_REF] Bannon | Studies in computer supported cooperative work[END_REF]. CSCW contains a number of core dimensions like:

Articulation Work: It consists of articulating distributed work of users. [START_REF] Schmidt | Taking cscw seriously[END_REF]. Awareness: Awareness is one crucial aspect of switching between work in solitude and collaboration. [START_REF] Herrmann | Awareness support for combining individual and collaborative process design in co-located meetings[END_REF]. Awareness provides important information about activities of collaborators and interactions with the shared workspace in order to place the user in the best context [START_REF] Dourish | Awareness and coordination in shared workspaces[END_REF].

Awareness is primordial for collaborative modeling. Nevertheless, awareness is little supported in commercial tools and research work. Therefore, we decided to do a study on this aspect. As awareness is centered on the needs of users, we decided to follow the user-centered design process. Our study is the first step of the process. The goal of our study is to know how modeling tools users work in collaboration. We want to know what the different articulation work types are and what awareness information is needed in these steps. To complete this study, we used GenMyModel and the many collaboratives projects constructed by users and we analyzed them. With this analysis, we determined three articulation work types. Then, for each articulation work type, we surveyed users of modeling tools to evaluate the importance of each awareness information. While we mainly contacted GenMyModel users for the survey, we also included users of other modeling tools in order to generalize our results: we took care to assess whether the modeling tool used influences answers. To go further with our surveys, we researched if correlations between distance between users, the size of the project, the size of the team or the context of the project, and awareness needs exist.

The remainder of the paper is organized as follows. In section 2, we will describe awareness in depth, what are awareness information types and how they are currently handled by commercial modeling tools and research works. In section 3, we will present the study with the analysis of collaborative projects to define different articulation work types. In section 4, we will link articulation work types with awareness information. From these links, we will look at the surveys for modeling tool users in section 5. Finally, we will present the results in section 6.

Awareness

In this section, we will present the CSCW dimension which mainly guides our experiment: awareness. Then, we will see how awareness is supported in modeling tools.

Global Definition

The most widely used definition of awareness is given by Dourish and Bellotti [START_REF] Dourish | Awareness and coordination in shared workspaces[END_REF] : "[...] an understanding of the activities of others, which provides a context for your own activities". Schlichter [START_REF] Schlichter | Awareness -the common link between groupware and community support systems[END_REF] built on this aspect of CSCW a few years later in order to reach and to maintain effective coordination of collaborative work. In his review of awareness in Distributed Collaborative Software Engineering [START_REF] Omoronyia | A review of awareness in distributed collaborative software engineering[END_REF], Omoronyia defines four types of awareness as follows:

Workspace Awareness. The up-to-minute knowledge of other participants interactions with the shared workspace [START_REF] Gutwin | Support for workspace awareness in educational groupware[END_REF]. Informal Awareness. The general sense of who is around, what they are doing, and what they are going to do [START_REF] Gutwin | Workspace awareness in real-time distributed groupware: Framework, widgets, and evaluation[END_REF]. Group-Structural Awareness. Knowledge about people roles and responsibilities, their positions on an issue, their status, and group processes [START_REF] Gutwin | Workspace awareness in real-time distributed groupware: Framework, widgets, and evaluation[END_REF]. Social Awareness. Information about the presence and activities of people in a shared environment [START_REF] Prinz | Nessie: An awareness environment for cooperative settings[END_REF].

These types refer to a series of questions people ask themselves when they collaborate. Table 1 shows a list of the main ones. Workspace awareness is the most studied in awareness literature [START_REF] Omoronyia | A review of awareness in distributed collaborative software engineering[END_REF], and it seems to also be the most important type in Distributed Collaborative Software Engineering. Even if awareness is the focus of many scientific works for decades, it is still a scientific issue. The April 2013 volume of Computer Supported Cooperative Work [START_REF] Kolfschoten | Differentiated awareness-support in computer supported collaborative work[END_REF] presents recent scientific results on awareness in different areas (distributed software development, model versioning, virtual team, social media, etc.). Additionally, the new direction of research relates to recent interactive technologies like large tactile surfaces. Yuill [START_REF] Yuill | Mechanisms for collaboration: A design and evaluation framework for multi-user interfaces[END_REF] reports case studies about awareness with such technologies.

In this part, we presented awareness information for collaboration. We must now know how awareness is supported in modeling tools.

Awareness in Modeling

In the previous part, we saw that awareness is important for collaboration and awareness involves displaying a lot of information. Now, we would like to know what modeling tools provide collaborative features, how they provide this collaboration and what awareness information they display. Few works exist about awareness in modeling tools. Both industrial tools and research prototypes do not implement collaboration in the same way. On the one hand, users of the Finally, the tool which has the largest support for awareness is Lucidchart5 which is a web-based tool with real-time collaboration. Lucidchart provides a chat panel where collaborators know who is connected and their names. Users can add comments on model elements in order to assign tasks to themselves or to collaborators. Nevertheless, we do not know if a user is working on a specific task when the user is editing the model. Lucidchart also allows users to revert the model to a revision, but users can not see differences between two versions. Thus, Lucidchart supports many awareness elements: Identity, Authorship, Intention partially, Intention history, Artifact partially, Event History and Presence. Thanks to the revision history, users can know who has changed the model, but they can not see what model elements have changed.

Research Prototypes.

The main research works on collaboration in modeling tools are centered on collaboration protocol, model merging, etc. but few deal with awareness and are centered on users. Both of the following research prototypes are web-based and provide real-time modeling.

The first is GEMSjax (a meta-modeling tool) [START_REF] Farwick | A webbased collaborative metamodeling environment with secure remote model access[END_REF]. In his works, Farwick briefly discusses awareness. He summarizes it as a chat and events to see which elements are currently selected but without giving more details. GEMSjax supports Authorship partially and Artifact partially information.

Thum with his work on SLIM [START_REF] Thum | Slim-a lightweight environment for synchronous collaborative modeling[END_REF] is akin to Farwick's work on the point of view of awareness. SLIM is a UML Case Tool for synchronous collaborative modeling based on a lock system to avoid conflicts. When a user clicks on an element, a lock is put in place to prevent modifications by another user. Concerning awareness, SLIM contains a chat to discuss, displays current connected users, and padlocks on model elements locked by other users . With these features, SLIM supports Identity, Presence, Authorship partially and Artifact partially.

Both tools support Authorship and Artifact partially, because if users work on different diagrams, they lose information since they can not see changes.

Other works exist on awareness but they deal more with the organization of awareness information. Gallardo [START_REF] Gallardo | An ontological conceptualization approach for awareness in domain-independent collaborative modeling systems: Application to a model-driven development method[END_REF] provides an ontology to organize workspace awareness information for modeling tools.

Issues. Awareness is a crucial aspect for collaborative work. Nevertheless, tools and research prototypes do not seem to be interested in awareness. A quick look to widespread collaborative authoring tools like Google Drive Applications or Office Web Apps shows that they provide a wider support of awareness: Authorship, Identity, Location, Artifact/Action, Artifact/Action History and Presence. Unfortunately, it seems difficult to assess whether the additional awareness features need to be applied in the modeling context without a thorough investigation.

The problem with tools and research prototypes is the multiplication of widgets in order to display information. However, as display area is limited, it is not possible to have more and more widgets to cover awareness elements. Furthermore, users risk a cognitive overload due to the amount of information. Therefore, we have to know what information is required the most. Then, we have to see if requirements vary not only according to different articulation work types but also according to the size of the team, the size of the project, the type of project which is modeled, the project's context or the distance between collaborators.

To complete these objectives, we have questioned people who have already used collaborative modeling through web surveys. These surveys determined what awareness information is relevant for the user. As we think that the relevance of awareness information varies according to articulation work types, first, we studied what these different articulation work types are. These articulation work types are presented in section 3. We will see that results on articulation work types allow us to determine what information is relevant for each type in section 4. In section 5, we will detail how we have built surveys for each articulation work type. Section 6 will present the results and discussions around them.

In future works, with these requirements, we will be able to implement better software support and also evolve the requirements to improve our knowledge on what is needed for collaborative modeling. We can note that our approach is user-centered with analysis, implementation and tests. This approach seems to be adapted because awareness is mainly a HCI issue.

Defining Articulation Work Types

The first step of our approach is to define different articulation work types. To do this, we analyzed GenMyModel user projects. In order to analyze GenMyModel user projects, we analyzed the database. We extracted collaborative projects with the following criteria:

-Public, to have the right to analyze the project's content.

-Not cloned from GenMyModel examples to avoid tests projects. GenMy-

Model examples can be cloned in order to discover GenMyModel's capabilities. -Recent, in order to contact users about a project they remember.

From March to mid-May, 508 projects met these criteria. For each project, we built users' activity sessions by analyzing launched actions on their projects as shown in figure 1. With these sessions, we can analyze how users interact with the model, and if they edit the model at the same time. For example, in figure 1, we can see numbers in rectangles. Each rectangle corresponds to a user session where actions were launched, and the number indicates the number of launched actions. We can see that the figure is divided into two parts. In the first, the user is the only one to make changes. In the second, user thampe initialized the project with 9 actions. Then, 2 collaborators joined him on the project, and they started to edit the model at the same time. They stopped for 10 minutes and started again until user angart is alone to modify the model. After angart stopped modifying the model, user thampe took the relay and modified the model by himself. Often, turn by turn and real-time articulation work types are used in the same project. We defined three different articulation work types, and now we have to link awareness information requirements with them.

Linking Articulation Work Types and Awareness

In this section, we will discuss what awareness information may be relevant for each articulation work types.

One Contributor

A plausible situation is that the only one contributor is an architect and others are the developers. Developers have to know when parts of the model are finished in order to code them. Furthermore, developers can give their ideas on model improvements. For this articulation work type, the relevant awareness elements are intention and opinion.

Users Modify Model Turn by Turn

Most of the awareness elements are from the past, because no other user has had interaction with the shared environment. The user needs information of what changes took place to understand the actual state of the model. Thus, users may have to know what the collaborators' current tasks are in order not to modify the same model parts. For this articulation work type, the relevant awareness elements are authorship, action history, intention, intention history, artifact history, location history, event history, andpresence history. During the analysis of the users activity sessions, we observed another important element. In fact, the time between login and the first command is superior than 1 minute. There are two possible reasons: it is the time needed for users to see all the changes since the last disconnection, or the users look at another browser tab while their model is loading. If the reason is the time needed to see changes since last connection, it means that past events are at least relevant when they log in to their projects.

Users Modify the Model at the Same Time

All awareness information may be needed for real-time collaboration, because the information about curent actions, collaborators, past actions, etc. could be required in order to understand the current state of the model.

Table 2 summarizes the related awareness elements according to the articulation work types.

OC TBT RT Identity X Authorship X X Action X Action history X X Intention X X X Intention history X X Artifact X Artifact history X X Location X Location history X X Gaze X View X Reach X Event history X X Opinion X X X Presence X Presence history X X Interest level X Emotional feelings X Availability X

Roles and responsibilities X

From the table 2, we defined questions to sort awareness elements by relevance for each articulation work type.

Developing Web Surveys

In the previous section, we defined what awareness elements are concerned according to the articulation work types. Therefore, we discussed with GenMy-Model users to define their requirements. To do this, we developed surveys to send to GenMyModel users who had projects which satisfied the aforementioned criteria. Moreover, we shared our surveys on social networks according to the articulation work types. We did this in order to have responses from people who do not use GenMyModel and to know if the use of GenMyModel influences results. Now, we will describe these surveys. For each, we asked them the following information:

-Project context (student project, business project, research project) -Modeled application type (users model for Desktop, Web or Mobile application) -Team size (1-3, 3-5, 5-10, 10+) -How far away are you from your collaborators? (We share the same building, town, country, we are over the world)

Each question corresponds to a potential element which can be correlated the awareness requirements. We will have to verify further if the correlations found impact the awareness requirements. Now, we will detail the different surveys according to the articulation work type.

One Contributor

Aforementioned possible awareness elements when collaborative projects have just one contributor are intention and opinion. For this articulation work type, we contacted the contributors of 308 projects by email, and we asked the following questions:

- The first, the second and the third questions determine if opinion is important or not for users and the way to know the opinion of their collaborators. The last questions target intentions. The goal of these questions is not only to know if Opinion and Intention are important for users but also to know how they obtain and share this information.

Users Modify Model Turn by Turn and at the Same Time

As most of the collaborative projects with many contributors use TBT and RT articulation work types, we defined one survey divided into two parts that concerned each articulation work type. In the previous section, we linked the articulation work types with awareness information. Thus, for each awareness information, we had to evaluate the information requirement. We asked the usefulness of awareness information on a scale from 1 to 4 where 1 is useless and 4 is useful. This pair scale forced users to have an opinion on the question. They could not be neutral. To simplify the survey, we generalized awareness information to avoid explaining the sense of each.

For example with RT, for Presence information, we asked the usefulness of Knowing if other collaborators are connected, and for Identity, we asked if the Name of connected collaborators is relevant.

Furthermore, we asked them to give the 5 most important elements aforementioned in order to classify awareness information by relevance. The evaluation of each information on the scale is complementary to the classification, because the evaluation is useful to detect inconsistencies in responses.

In the second part, with the same type of scale, the respondents evaluated the usefulness of information for TBT. This is when the user works alone on the project. As for RT, we simplified the surveys and instead of asking the usefulness of Presence History, we asked the relevance of Who was connected when you were offline.

Moreover, we asked the question When you open the model, what is the first thing you do? in order to understand why the time between login and the first command is more than one minute. After the questions, we provided a section for comments so that users could offer their ideas about collaboration. For this survey, we contacted 392 collaborators from 508 projects which satisfied the aforementioned criteria. In this email, we asked the person if they wanted to help us to improve collaboration features, and we waited for their responses. It was only to open the discussion. When users were ready to help us, we sent them the online survey made with Google Form. We also posted this form on LinkedIn UML professionals groups in order to have responses from people who do not use GenMyModel. In sharing the survey with others, we wanted to know if the tool influences responses.

Results

The following results are presented by articulation work types.

Ranking Awareness Information by Relevance

One Contributor. For this first survey, we had 17 responses from the 308 contacted users.

Fig. 2. Survey responses for OC

Figure 2 summarizes the results of the first survey. We learned that it is mostly students who use the one contributor articulation work type. Therefore, most of the respondents model for desktop applications. Most of the respondents work in little groups, and most of them share the same building. Most respondents need the opinion of their collaborators even if they do not make modifications on the model. For the question, Why do you need the opinion of your collaborators?, they answered that they wanted the advice of others in order to improve the quality of the model.

Concerning intentions, the respondents are more divided. Less than half shared their tasks with others. For these users, all tasks were written in a product and issue tracking product, in a Facebook group or were defined during meetings.

Users Modify Model Turn by Turn.

With this survey, we had 50 responses, 35 are GenMyModel users contacted by email, and 15 others came from LinkedIn professional groups for modeling. As figure 3 shows, the three most important awareness elements when users modify the model turn by turn are Action History/Artifact History, Authorship and Intention. Discussions. If we compare the required awareness elements and the existing information in modeling tools, we can see there is a gap. For OC, even if the number of respondents is low, responses give some cues about how they collaborate with only one contributor. On the one hand, modeling tools have to provide support with issue tracking tools like Jira, Mantisse or their own solution, because half of the users share their tasks with their collaborators. On the other hand, as opinion is important, modeling tools have to find a way to retrieve the opinion of collaborators. Currently, the modeling tool with the largest support of awareness is Lucid Chart which provides task features. Nevertheless, Lucid Chart does not allow users to obtain the opinion of collaborators. It is also interesting to mention that tasks and opinions are missing in collaborative authoring tools.

For TBT, the most important awareness information is Artifact/Action History. This information is not covered in modeling tools and research prototypes. As users work alone in TBT, they do not need information about the current changes or their collaborators. Thus, it is logical to have information concerning Artifact/Action History first. The second most important information is related to the first. Respondents want to know the past changes, and furthermore, they want to know who has made these changes. Finally, users want to know what is the current tasks of their collaborators. It can be easily explained. Users do not want to modify model parts which can be modified by others. This information is the only one which is provided by Lucid Chart, but only partially, because it is not possible to know if users are working on tasks. We can see that modeling tools provide a little support for TBT. Even research works in collaborative modeling do not cover the most important awareness information for TBT. In general, the ontology of Gallardo does not refer to past events. Concerning collaborative authoring tools, their awareness support seems fit to TBT as the two most requested information are provided. However, tasks are still missing.

Concerning RT, the most important awareness elements are Presence, Identity, Action/Artifact, Intention and Authorship. As changes are not related to tasks, and users can not follow changes on another diagram, Lucid Chart does not cover Action and covers partially Intention and Authorship. As for TBT, collaborative authoring tools do not provide information about tasks.

At the beginning of our study, we observed that the time between login and the first modification is more than one minute. The first thing users do when they log in to the project is to look at the last changes since their last disconnection. Nevertheless, the past awareness information does not appear in the most required information defined by users. It means that they need this information only when they log in to be aware of the project events since their last disconnection.

In section 2, we said that workspace awareness is the most studied in awareness literature. The importance of workspace awareness is confirmed for modeling tools with our study. Most of the important awareness information in the ranking is workspace awareness information.

Correlations with the Awareness Requirements

For each articulation work type, we researched if the size of the team, the size of the project, the modeled application type, the context of the project, the distance between collaborators or if being a GenMyModel user (named elements in the rest of the article) were correlated with awareness information requirements. To do this, we tested the correlation with responses where respondents had to answer on a scale from 1 to 4. To complete the correlation test, we used a Pearson Correlation test with the SPSSStatistics tool. This test gives correlations between 2 variables. To begin with the tests, we verified that elements were independents. As elements were independents, we verified if they change awareness requirements for each articulation work type.

One Contributor. The Pearson Correlation tests did not reveal links with intention or opinion awareness information. As the number of respondents is low, it is not surprising. It could be interesting to go further with this study.

Users Modify Model Turn by Turn. We present the correlations with awareness requirements for TBT. All of them are resumed in figure 5. In this figure, solid arrows show that the awareness information requirement increases with the element. The values inside brackets mean that the requirement increases with the conditions represented by these values. Significance levels are indicated with stars (*** for 0.01, ** for 0.05 and * for 0.10).

For example, in the figure, we can see that opinion requirement increases with the size of the team. We can also see that Presence History information is more important for users who model a desktop application. Users Modify the Model at the Same Time. We present the correlations with awareness information requirements for RT. Figure 6 shows these correlations. In this figure, dotted arrows mean that the awareness information requirement decreases with the associated element.

Discussions.

For TBT, the opinion requirement is higher when the size of the team increases. We are not able to explain why and we will have to discuss this with modeling tool users to understand. In the case of a student project, requirements for Opinion and Event History are more important. It is not surprising, because students are not modeling experts. need more information from others to build their models together. If modeling tools asked at the creation of the project what the type of project it is, it could be possible to customize displayed awareness information. With this option, users would only see the information important to their projects without useless information. Furthermore, for Intention History information which is at the fifth position in the ranking, the need increases when users model for a desktop application. Currently, we do not have an explanation about the correlation between modeled application type and awareness information. We have to examine user behavior in depth to understand this correlation. Nevertheless, in the case of users who model a desktop application, the ranking could be a little different.

For RT, the size of the team and the size of the project are widely correlated with the awareness information requirements. When the size of the project increases, users have more of a need to know intentions and changes done on the model. It is not surprising, because they have to organize themselves for a large project and know the last changes to understand the current state of the model. As intention and past changes on the model are already well ranked, it is very important to highlight this information when the project is large. The larger the project becomes, the more important this information is. As for TBT, opinion requirement increases with the size of the team. As the tool used by the survey respondents is not correlated with the results, the rankings and the correlations are applicable for all modeling tools.

Despite correlations exist with the awareness information requirement, modeling tools and research work do not vary the display of awareness information. The same is valid for collaborative authoring tools. We will have to realize other studies with modeling tool users to understand why the modeled application type is correlated with awareness information requirements. With these studies, we could refine ranking according to the aforementioned correlations.

Furthermore, in this study, we did not test the correlations of multiple elements at the same time, it will be the topic of another study.

Conclusion

In this paper, we have seen that GenMyModel was developed to counteract installation problems which can be time-consuming, and the fact that users have to ensure they use the same version of the modeling tool to share their models. As CSCW is user-centered, particularly awareness, we focused our research on this dimension. We looked at awareness support in commercial modeling tools and research prototypes. They provided a little support of awareness. We decided to launch a study with modeling tool users by following the user-centred design process. To begin the study, we analyzed user projects built with GenMyModel in order to categorize how users collaborate, and we defined three articulation work types: projects with only one contributor and projects with many contributors, divided into two categories. On the one hand, we have projects which use a real-time collaboration feature, on the other hand, projects where users edit the model turn by turn. For each articulation work type, we defined what awareness elements could be needed for users.

After this analysis, we have the following contributions. The first is the ranking of awareness elements according to the articulation work type. The ranking is different for each. First, for projects which have only one contributor, the awareness elements required are intention and opinion. Then, for the turn by turn articulation work type, the most important awareness information is artifact/action history, authorship and intention. To finish, the real-time articulation work type requires the support of presence, identity, artifact/action, intention and authorship.

The second contribution is the correlations between elements and the awareness requirements. In fact, for RT, the size of the project, the size of the team, the modeled application type and the context of the project increase/decrease the Intention, Identity, Availability, Role, Artifact/Action History, Opinion, Location, Reach, Presence History, Feelings and Event History requirements. For TBT, the requirements are correlated with the size of the team, the context of the project and the modeled application type. The correlated requirements are Opinion, Event History, Intention, Intention History, Presence History and Authorship. We will have to verify these correlations when we implement the awareness information. We can then verify if the awareness requirements change according to aforementioned elements. Except Opinion and Intention, all required awareness features for collaborative modeling have already been proposed by collaborative authoring tools. It would be interesting to study to what extent these features may catch the interest of users of these tools.

As it is not possible to display too much information due to a limited display space, and in order to prevent the cognitive overload, we will study if navigation is possible between the most important awareness elements. For example, when the collaborators' identities are displayed, what possible awareness elements could be displayed next to the users?

First, we will have to define a navigation system for awareness information, and then, we will find out how to display this information. To do this, we will follow the next two steps of the user-centered design process, implementation and tests.

Fig. 1 .

 1 Fig. 1. Examples of sessions

Fig. 3 .

 3 Fig. 3. Ranking of responses for TBT

Fig. 4 .

 4 Fig. 4. Ranking of responses for real-time collaboration

Fig. 5 .

 5 Fig. 5. Correlation between parameters and awareness elements when TBT

Fig. 6 .

 6 Fig. 6. Correlation between parameters and awareness elements for RT

Table 1 .

 1 Awareness answers to collaboration raised questions[START_REF] Steinmacher | Awareness support in distributed software development: A systematic review and mapping of the literature[END_REF] collaborators are working, they are notified that a collaborator has made changes on this element. It involves support of Identity, Presence, Authorship partially and Artifact partially awareness elements. Authorship and Artifact support is partial because if the user is not working on the same diagram as your collaborators, the user can not know who has changed the model.Like Gliffy, Creately 4 is a web-based tool. Creately provides real-time collaboration like Visio. Available features to display awareness information are the list of connected users with their names, a focus on what elements are selected by collaborators, and comments on model parts. The features concern only real-time information and related awareness elements are Identity, Authorship partially, Artifact partially and Presence. Authorship and Artifact support is partial for the same reason as in Gliffy.

	Awareness dimension Element	Question
		Identity	Who is that?
		Authorship	Who is doing that?
		Action	What are they doing?
		Action history	How did that operation happen?
		Intention	What goal is that action part of?
		Intention history	What goal was that action part of?
	Workspace	Artifact Artifact history	What object are they working on? How did this artifact come to be in this state?
		Location	Where are they working?
		Location history	Where has a person been?
		Gaze	Where are they looking?
		View	Where can they see?
		Reach	Where can they reach?
		Event history	When did that event happen?
		Opinion	What is their opinion?
	Informal	Presence	Is anyone in the workspace?
		Presence history	Who was here and when?
		Interest level	How interested are they?
	Social How are they feeling? tool share the same environment and edit the same version of the model. On Emotional feelings
	the other hand, users have to retrieve the version of the model locally, modify
	it and commit and optionally merge the result if users have modified the same
	elements. Furthermore, in this study, we did not differentiate modeling tools
	and diagramming software. The difference between both tool types is that the
	model made with a modeling tool is valid. With modeling tools, many actions
	are forbidden for compliance with model specifications contrary to diagramming
	software. Most desktop modeling tools do not appear in our presentation of
	modeling tools. They provide a classic revision control system for collaboration.
	Visio provides the best awareness support, so we decided to present only Visio
	among the desktop modeling tools.
	Commercial Tools. Concerning commercial modeling tools, Gliffy 2 is a web-
	based tool and provides a desynchronized environment. Each collaborator has a
	local version of the model. Collaborators do not know if others are editing the
	model or on what they are working. Awareness information is missing.
	Contrary to Gliffy, Visio 3 is a desktop tool but also provides desynchronized
	collaboration. Until the user saves the model, the user can not see changes done
	by collaborators.When users are editing the model, they know the number of
	connected collaborators and their names. If they work on elements close to those

Table 2 .

 2 Possible awareness elements used in articulation work types

	Element

http://www.genmymodel.com/ R. Meersman et al. (Eds.): OTM

2014, LNCS 8841, pp. 382-399, 2014. c Springer-Verlag Berlin Heidelberg 2014

https://www.gliffy.com

http://creately.com/

https://www.lucidchart.com/

Availability

Are they available? Group-structural Roles and responsibilities What are their roles/positions?


Michel Dirix
email: michel.dirix@axellience.com

Alexis Muller
email: alexis.muller@axellience.com

Vincent Aranega
email: vincent.aranega@axellience.com

GenMyModel : An Online UML Case Tool

Keywords:

Costs and markets lead engineering teams to collaborate from different locations all over the world. Modelling tools are present in development processes to produce complex software and these tools have to be highly collaborative to permit teams to be productive. Axellience tries to resolve issues about distributed collaboration and modelling with GenMyModel.

Introduction

Building complex software is a collaborative activity where modelling holds an important place. Since a decade, outsourcing and offshoring projects or part of them have become regular practices in software industry. These ones can have different reasons like the need to cut down costs or to explore new markets. Collaboration between project team members suffers from resulting geographical distribution.

Software practitioners usually draw diagrams when they design new applications, maintain existing ones or discuss with their clients using modelling tools [START_REF] Grossman | Does uml make the grade? insights from the software development community[END_REF]. Besides, models are important to manage knowledge and provide an efficient support to coordinate activities when the projects aim at producing complex software. It is important that modelling tools intent to support collaboration in the context of distributed teams, that is to say, to provide similar working conditions as co-located settings. Whitehead shows that the trend concerning collaboration support is the arrival of web-based tools in every phase of software development [START_REF] Whitehead | Collaboration in software engineering: A roadmap[END_REF]. Their main advantage is that they do not require any installation or configuration: teams are quickly ready to work.

Axellience was launched from this observation and had the support of INRIA in April 2012. Now, Axellience offers GenMyModel which is an online UML and generator tool. Axellience has began to communicate about a beta-version of GenMyModel since January 2013 and there are already nearly a thousand of users spread over in more than 70 countries. Some models already reach more than 50 classes elements and includes several hundreds of model elements.

GenMyModel

The promises of SaaS (Software as a Service) is to allow users to access to services without installation or configuration. Users find the same environment no matter where they connect from. In addition, SaaS applications can be used by users from anywhere, anytime, from any device and operating system, and users do not have to update their application. So, GenMyModel is online, in SaaS mode and its Graphical User Interface is shown in the figure 1. The intention of GenMyModel is to accelerate the modelling phase. Users are ready to work quickly and they access GenMyModel and the models from anywhere at anytime. For example, an architect can begin to model at his/her office, continue at home and present the result to the client the day after. Today, GenMyModel supports Class Diagrams and Use Case. Others are in development. From Class Diagrams, GenMyModel offers its users the possibility to generate the code to multiple targets like Java, Java-JPA, SQL. Others will be added. In addition, the code is preserved throughout different generations. So, users can edit their code, model again, re-generate without code loss. Nevertheless, in most cases, a generator is not completely adapted to users needs. GenMyModel will add a generator upload service where users would add their own generators.

Another benefit of the SaaS applications is the simplification of real-time collaboration [START_REF] Brunelière | Combining Model-Driven Engineering and Cloud Computing[END_REF]. Real-time collaboration is an ongoing work into GenMyModel and a first version will be available soon. We are working on the model synchronization between users and the rights management. In the longer term, we have to study what kind of information is necessary to display to users in order to facilitate collaboration. Future work will be on model repositories too. We plan to propose model repositories with versioning facilities. Thereby, users will can return to next version of their model.

One of the aims of GenMyModel is to offer a platform for specific needs or experimentations. For that, usage of GenMyModel will be free for public projects, allowing users to easily experiment and share their work. Additionally, the access to the model repositories will be granted to other tools though an API. This API will contain the generator upload service. By opening this API, Axellience wants to continue the collaboration with research laboratories where Axellience is already engaged.

3 Demonstration content 1. How to access to GenMyModel;

We will create a GenMyModel user in less than 30 seconds and will access to GenMyModel 2. Simple model creation;

We will present the GenMyModel Graphical User Interface and will create a class diagram.

Code generation;

From a simple model, we will generate associated code using the Java-JPA generator. This generation will be uploaded into a Github repository and we will show the generated code and annotations.

Model modification and code regeneration;

We will edit the generated code from a code editor tool in the Cloud. Then, we will edit our model to add new properties and we will generate the code again to show that new generations do not modify the code edited before.

Current state of collaboration.

To conclude, we will show our ongoing work on collaboration in editing the same model with two users.

Fig. 1 .

 1 Fig. 1. GenMyModel Graphical User Interface