=Paper=
{{Paper
|id=Vol-1805/Jolak2016HuFaMo
|storemode=property
|title=Towards a New Generation of Software Design Environments: Supporting the Use of Informal and Formal Notations with OctoUML
|pdfUrl=https://ceur-ws.org/Vol-1805/Jolak2016HuFaMo.pdf
|volume=Vol-1805
|authors=Rodi Jolak,Boban Vesin,Marcus Isaksson,Michel R. V. Chaudron
|dblpUrl=https://dblp.org/rec/conf/models/JolakVIC16
}}
==Towards a New Generation of Software Design Environments: Supporting the Use of Informal and Formal Notations with OctoUML==
https://ceur-ws.org/Vol-1805/Jolak2016HuFaMo.pdf
Towards a New Generation of Software Design
Environments: Supporting the Use of Informal and Formal
Notations with OctoUML
Empirical Study
Rodi Jolak, Boban Vesin, Marcus Isaksson, Michel R. V. Chaudron
Joint Department of Computer Science and Engineering
Chalmers University of Technology and Gothenburg University
Gothenburg, Sweden
{jolak,vesin,chaudron}@chalmers.se
imarcus@student.chalmers.se
ABSTRACT serve designers to inspect and develop one design idea as
Software architects seek efficient support for planning and well as reflect on some other alternatives [13].
designing models. Many software design tools lack flexibility On the one hand, whiteboards are commonly used for
in combining informal and formal design. In this paper, we sketching initial software design, quite often by many peo-
present OctoUML, a proof of a concept of a new generation ple simultaneously [1]. They support informal design and
software design environment that supports an effective soft- do not constrain the notation being used. However, stan-
ware design process. The system provides options for collab- dard whiteboards lack of integration with subsequent soft-
orative software design and different input methods for cre- ware elaboration tools. Hence, re-modelling is difficult and a
ation of software models at various levels of formality. The time-consuming task. On the other hand, CASE tools (e.g.
design and architecture of OctoUML are also presented. The StarUML, Rational Rose, Enterprise Architect, etc.) pro-
evaluation shows that OctoUML provides a user-friendly en- vide means to store and modify designs. However, they sup-
vironment and has the potential to effectively support the port one or more formal notations and hence restrictively re-
activities of the designers. quire designers to use those specific notations for modelling.
Actually, designers often sketch and use ad hoc notations
that rarely adhere to standards like the Unified Modelling
CCS Concepts Language UML [15].
•Software and its engineering → Model-driven software In previous work, we presented our vision on a new gen-
engineering; Design languages; Unified Modelling Language eration of software design environments [4]. One of the
(UML); System modelling languages; characteristics which we proposed for such environments is
that they should be capable of supporting both informal
and formal modelling. In other words, they would combine
Keywords the advantages of both whiteboards and CASE tools, and
Sketching; Informal and Formal Desing; Recognition; Multi- therefore be able to bridge the gap between early design
touch; Design Environment, UML process (when designers often sketch their ideas) and for-
malization/documentation process. To realize our vision, we
developed a software design environment called OctoUML1
1. INTRODUCTION [10]. This environment can be run using a number of input
As software systems are gaining increased complexity, the devices ranging from desktop computers over large touch-
importance of efficient software design tools is also increas- screens to large electronic whiteboards. It allows simulta-
ing. Software models change frequently and are quite often neous creation of both informal freehand sketches (using
updated by many designers simultaneously [3]. These mod- fingers or styluses) and formal computer-drawn notations,
els should present a description of systems at multiple levels e.g., UML class diagrams. We have enriched our tool with
of abstraction and from different perspectives. Therefore, it some features, functionalities and services in order to sup-
is crucial to provide software design tooling that provides port designers’ activities and provide a practical and inspir-
possibilities for efficient and collaborative development as ing user experience. Further details on these aspects will
well as options for creation and evolution of software mod- be described in Section 3. To assess our concept, we asked
els and architectures. some subjects to evaluate OctoUML and give feedback on
Sketches, or depictive expressions of ideas, pre-date writ- its usability. The following questions are addressed:
ten languages by thousands of years [19]. Many designers
tend to sketch their initial ideas on the whiteboard [20]. • Does our tool provide a usable environment consider-
These sketches present an intuitive way to prototype, com- ing issues like ease of use, efficiency and user satisfac-
municate and record their thoughts. Sketches can facilitate tion?
discovery of new objects and foster new design ideas [18].
1
They effectively support the process of software design and demo video: https://goo.gl/PmuUf8
• Does support for mixing informal and formal notation drawings were temporary and usually erased after producing
better support the software design process? the formal diagram.
Magin and Kopf [11] created a multi-touch based system
This paper is organized as follows: section two describes allowing users to collaboratively design UML class diagrams
the related work. Illustration of our approach for supporting on touch-screens. They have also implemented a new al-
exploratory and collaborative software design is presented in gorithm to recognize the gestures drawn by the users and
section three. We provide the design architecture details of to improve the layout of the diagrams. However, their tool
OctoUML in section four. Evaluation and results are pre- does not allow for informal freehand sketching of arbitrary
sented in section five. We discuss the results in section six. notations.
Threats to validity are presented in section seven. Finally, Baltes and Diehl [1] examined the usage of sketches in
we conclude the paper and illustrate our plan for future work software engineering activities by conducting an exploratory
in section eight. study in software companies. The results showed that the
majority of the sketches were informal, and the purposes
2. RELATED WORK of sketches were related to modelling, explaining or under-
standing. Baltes and Diehl also revealed that the sketches
CASE tools support software development activities such
were archived digitally for re-visualization and future use.
as diagramming, code generating and documentation [8].
Like us, they think software design tools should enable in-
However, software designers consider such formal tools overly
formal design sketching.
restrictive and limitative of their expressiveness [5, 8, 9].
Whiteboards are rather simple to use. In fact, they are
frequently used by software designers due to their role in 3. APPROACH
promoting creativity, idea generation and problem solving Our motivation for creating OctoUML is to provide a more
[6]. Electronic whiteboards provide the perspective for bet- intuitive, inspiring and efficient tool to support exploratory
ter software design support by permitting the management, and collaborative software design. Key innovations of our
control and maintenance of the contents [12, 5]. approach are: (i) enabling users to create and mix both
Mangano et al. [12] identified some behaviors that occur informal hand-drawn sketches and formal computer-drawn
during informal design. In particular, designers sketch dif- notations at the same time on the same canvas, (ii) providing
ferent kind of diagrams (e.g. box and arrow diagrams, UI a selective recognition mechanism that is used to transform
mockups, generic plots, flowcharts, etc.) and use impromptu hand-drawn sketches into formalized contents, and (iii) en-
notations in their designs. The authors implemented an in- abling of multi-user support on a single input device. In the
teractive whiteboard system (called Calico) to support these next subsections, we describe those novel aspects in more
behaviors and identified some ways where interactive white- detail. Table 1 shows the differences between our approach
boards can enable designers to work more effectively. and the related work.
Wüest et al. [22] stated that software engineers often use
paper and pencil to sketch ideas when gathering require- Tool Notation : Informal(IF)/Formal(F) Recognition Multi-touch
Flexisketch IF (hand-drawn) predict symbols based N/A
ments from stakeholders, but such sketches on paper often on incremental learning
need to be modelled again for further processing. A tool, SUMLOW IF and F, but not simultaneously holistic recognition N/A
Knight IF and F, but not simultaneously eager recognition N/A
FlexiSketch, was prototyped by them to combine freeform Calico IF (hand-drawn) beautification of shapes N/A
sketching with the ability to annotate the sketches inter- OctoUML mix of IF and F (simultaneously) selective recognition enabled
actively for an incremental transformation into semi-formal
models. The users of FlexiSketch were able to draw UML- Table 1: Comparison of OctoUML with some other
like diagrams and introduced their own notation. They were tools mentioned in the Related Work section
also able to assign types to drawn symbols. Users liked the
informality provided by the tool, and stated that they would
be willing to adopt it in practice. 3.1 Informality and Formality
Chen et al. have developed SUMLOW [5], a sketching- Based on studies done by [8, 12, 13], we report some com-
based UML design tool for electronic whiteboard technol- mon practice behaviours that occur during software mod-
ogy. It allows the preservation of hand-drawn diagrams and elling meetings:
supports the manipulation of them using pen-based actions.
UML sketches can be formalized and exported to a 3rd party • Designers combine informal and formal models.
CASE tool.
• Designers often alternate between CASE tools and white-
Damm et al. [8] conducted user studies in order to under-
boards.
stand the practice of software modelling. They observed
that designers alternate between whiteboards and CASE • Designers prefer all-purpose sketches which refer to
tools, extend the semantics of the notations to support the many scenarios over sketches dedicated to a single sce-
design activities and allow expressiveness, sketch new ideas nario.
informally, and actively collaborate when they work in teams.
• Sketches rarely follow notational convention.
The authors considered that a usable modelling tool should
be designed to come across the aforementioned observed be- • Sketches are used at different levels of abstraction.
haviours. They developed a tool called Knight. Knight sup-
• Designers sketch different types of diagrams with dif-
ports informal and formal modelling using gestures on an
ferent perspectives.
electronic whiteboard. In order to achieve intuitive interac-
tion, Knight uses composite gestures and eager recognition • Designers extend formal notations in order to explain
of hand-drawn elements. Damm et al. showed that informal their ideas to others.
undo/redo commands in order to move easily between the
two forms; sketchy and formal.
3.3 Layering and Multi-touch
Having been inspired by the recent version of the Altova
UModel tool 2 , we decided to equip our tool with a layering
mechanism. In particular, the software design is part of one
layer which we call the formal layer. While another layer, the
informal layer, contains the informal sketchy elements e.g.
hand-written comments, illustrative drawings, highlighting
arrows or circles, etc. The user can then select to see com-
bined layers or layers in isolation. A key advantage of such
layers is that they allow the isolation of informal and for-
mal elements. As a consequence, designers will be able to
move and edit the content of each layer independently with-
Figure 1: Combination of different notations on the out disturbing the rest of the design. For instance, users
same canvas might want to archive, print or share the formal designs
without including the sketchy elements. In that case, the
formal layer can be a solution for them. On the other hand,
Whiteboards support informal design by ensuring the users having the two layers combined could help reveal some ex-
a total freedom in creating and using a variety of modelling isting ambiguities in diagrams as well as give more insights
notations. For example, informal hand-drawn sketches can to increase one’s understanding of concepts, mainly, during
be used to express abstract ideas representationally, allow diagram reviewing cycles. Baltes and Diehl stated that quite
checking the entirety and the internal consistency of an idea often two or more people are involved in sketching when the
as well as facilitate the development of new ideas [18]. In- whiteboard is used as a medium [1]. We enabled our tool
formal sketches, as well as various informal tools are used by to support multi-touch. Multi-touch is an interaction tech-
software developers during their work activities [5, 12, 21]. nique that permits the manipulation of graphical entities
However, some tasks like model transfer and persistence are with several fingers at the same time. This option allows
difficult and require a redundant work by re-drawing the de- concurrent collaborative modelling. In particular, it enables
sign solution using a Computer-Aided Software Engineering two or more designers to simultaneously work on the same
(CASE) tool. CASE-tools provide a limited set of mod- canvas of the same device, especially when the device is an
elling notations, hence restrict designers’ expressiveness by interactive whiteboard or a large touch screen.
imposing the notation that can be used. Modelling tools
should be holistic in order to support software designer’s 3.4 Other features
imagination and creativity. To that end, our tool allows a CASE tools are better than whiteboards when we con-
simultaneous creation of both informal and formal notations sider some aspects such as undo/redo and re-sizing utilities.
on the same canvas. The informal notations can be created For that, we enabled our tool to support the aforementioned
using free-hand sketches, while the formal notations can be features in order to allow designers to easily correct mistakes
either hand-drawn following a specific syntax or created us- and have liberty to change the size of the elements. Some-
ing computer-drawn ready-to-use elements available in the times designers complain about the limited size of tools’
menu. At the moment, and for the creation of formal ele- modelling space or canvas which may not be enough to cap-
ments, our tool mainly supports UML class diagrams, but ture all their design ideas. To overcome this inconvenience,
in the future we aim to support other types of UML dia- the drawing canvas of our tool supports panning and zoom-
grams. Figure 1 illustrates the main canvas of our tool. It ing in/out actions. Panning allows users to drag the canvas
shows how our tool allows the combination of informal and in all directions in order to find more space for their designs.
formal notations on the same canvas. Moreover, it shows In addition, zooming helps to change the scale of the can-
how designers can transform the notations from one state to vas, hence to enhance the visibility and readability of the
another i.e. from informal to formal and vice versa. designs.
3.2 Recognition 4. DESIGN
Walny et al. [21] demonstrated that sketches have a life- In this section we present the current architecture of Oc-
cycle. In particular, a sketch starts as an informal repre- toUML. The architecture is organized in a way to effectively
sentation of one idea and later on ends up having a formal fit with complex business work-flows, data, and security
representation. To facilitate that process as well as support needs as well as to allow for future integration of different
tasks like: model transfer to third-party CASE tools, code modules and other enterprise applications.
generation and model documentation, our tool supports the The key architectural components of OctoUML are pre-
transformation of UML hand-drawn elements to formalized sented in Figure 2. The environment contains three major
computer-drawings and vice versa at any time during the components: UI component, Data cloud and Services. The
modelling sessions. This has been made available using Pa- current version of the system offers only the UI and data
leoSketch, a primitive sketch recognition system [14]. There cloud components. Additional services will be added during
are two aspects that favor the flexibility and elasticity of the future development.
recognition process. Firstly, we allow users to select what
2
they want to recognize in advance. Secondly, users can use http://www.altova.com/umodel.html
Figure 2: Architectural Components of OctoUML
(currently implemented components are presented in green)
UI component consists of two separated but interconnected methodology [7], and used NVivo 3 in the qualitative data
parts: Presentation manager and Input unit. The Presenta- analysis process. More details together with the results are
tion manager provides means for performing stylus or touch- reported in the following subsections.
based input commands on devices being used. Drawing lay-
ers include support for both informal and formal modelling 5.1 Participants and Modelling Expertise
layers. Depending on the chosen layer, users are presented Sixteen software engineering students and researchers were
with an appropriate toolbar. The Command tools are re- involved in doing the assignment and subsequently the in-
sponsible for transferring the inputs from users to different terviews. In particular, there were four master students,
controllers. The Graph controller allows switching between ten PhD students and two post-doctoral researchers. Five
different input techniques as well as combining of different participants have an experience in industry for some period
layers. The Input unit is responsible for processing different of time. Twelve people worked on the design task in pairs,
inputs. In particular, a Sketch recognizer is provided to rec- while the rest worked individually. Overall, the participants
ognize and transform informal models into formal concepts, are experts in software modelling and have some experience
and hence allows to maintain and transfer the designs for in using UML. In fact, nine participants claimed to have high
further processing tasks. A Multi-touch controller captures expertise in software modelling, five have a moderate exper-
and coordinates the inputs from different touch-points. All tise, while only two have low expertise. All participants
the program data are saved and stored in the Data cloud. believe that software design is a critical task for successful
Our tool uses a set of data structures to manage and main- software development and evolution. In previous occasions,
tain the sketched elements, formalized designs, and session all but one participant did software modelling with other
control for users. The modelling process and dynamic as- people in teams (collaborative modelling). The participants
pects of the system are presented in Figure 3. have a practical experience with a variety of modelling tools.
These tools range from whiteboards, pen&paper to CASE
tools like Enterprise Architect, Visual Paradigm, Dia, Ar-
5. EVALUATION goUML and Papyrus.
In order to answer the research questions presented in 5.2 Design Task
Section 1, we prepared user studies. Sixteen subjects were
We formulated a simple design problem, and asked the
engaged in a design assignment. The assignment was to cre-
participants to design a domain model class diagram solu-
ate a UML class diagram of a given scenario using our tool.
tion of it using OctoUML. Before starting with the task, we
To give a global overview of the subjective assessment of our
gave the participants a brief introduction regarding the fea-
tool’s usability, we asked our subjects to answer the System
tures and functionalities of our tool. We directly observed
Usability Scale (SUS) questionnaire [2]. Furthermore, we
the design processes and took notes. When the participants
planned semi-structured interviews using both closed and
asked some specific questions about the design assignment,
open questions. The interviews were held after the comple-
we told them that it is up to their interpretation. They
tion of the design assignment. Our main concern was to get
could, however, ask questions concerning the design envi-
feedback from the participants regarding their experience
ronment e.g. how to use certain tools. The participants
in using OctoUML, so we focused on qualitative data more
3
than quantitative data. We followed the grounded theory http://www.qsrinternational.com/
Figure 3: The Modelling Process
(currently supported activities are presented in green)
did not get any help unless they asked for it. An interac- on. In fact, the participants became more confident as they
tive whiteboard was chosen as an input medium, and the were gradually and progressively interacting with the tool.
design sessions were video-recorded. The text of the design Moreover repeating some actions, such as selection and cre-
assignment is presented in the following paragraph. ation of classes, let them in some manner experience our
E-Learning System. The system is used by teachers, stu- environment’ functionalities.
dents and an administrator (who is also a teacher). One
teacher is responsible for many courses. Consider that courses 5.3 SUS Questionnaire
consist of many topics. Students can enroll into different The System Usability Scale is an easy, standard way of
courses. There is a news section within the system. Teach- evaluating the usability of a system [2]. It is a form contain-
ers add news for a specific course and the students can read ing ten statements, and users provide their feedback on a
them. Every course ends with an evaluation test. Teachers 5-point scale (1 is strongly disagree and 5 is strongly agree).
create a test and the students have to do it. The students It effectively differentiates between usable and unusable sys-
get one of these grades: fail, pass, good, or very good. tems by giving a measure of the perceived usability of a
system. It can be used on small sample sizes and be fairly
5.2.1 Design Task Observations confident of getting a good usability assessment [17]. The
participants were given the forms directly after they finished
While carrying out the design task, the participants were
with the design task. We considered the SUS score as a “pre-
observed in order to understand their activities. This was
liminary feedback” on the usability of our tool. However, in
done in two different ways: First, we directly observed the
order to consolidate the current findings, more people will
behaviour of the participants as they were performing the
be involved in testing our tool and answering the SUS ques-
task and took notes. Second, the participants were recorded
tionnaire.
via a digital video-camera. This let us observe their be-
haviour indirectly through records of the task. The notes
which we took were expanded by transcribing elements of
5.3.1 SUS Result
the video recordings. At the beginning of the task the par- All sixteen participants filled out the SUS questionnaire.
ticipants spent around one minute reading the assignment, We calculated the SUS score reported by each participant.
then they proceeded with designing the solution. While car- After that, we calculated the average of the usability values
rying out the design task, some participants first created of all participants to obtain the overall OctoUML usability
many UML classes then they associated them with differ- score4 . The lowest score was 65 and the highest was 95,
ent kind of relations. Other participants followed another with an average score of 78.75. It falls at around the 80th
strategy by creating two classes in the first place, then, they percentile, and would result in a grade of a “B” which is a
defined the relation between the two classes before contin- high usability score according to [16].
uing to create other UML classes. Even when two people
were working on the same design at the same time, they 5.4 Interviews
rarely interacted with the e-whiteboard at the exact same After answering the SUS questionnaire, each participant
time. Most of the participants tended to create the classes was involved in a semi-structured interview. The conversa-
sequentially, and they discussed the properties of one class tions were recorded using a digital voice recorder. The in-
before proceeding with the creation of another class. Fur- terviewers took some notes which were expanded afterwards
thermore, they often divided the work between themselves, by transcribing the audio recordings. Both closed and open
e.g. one was interacting with the tool to create classes, and questions were used, and respondents’ answers were quanti-
the other one was reading the assignment as well as pro- tatively and qualitatively analyzed.
viding ideas for the solution. The participants were given
a brief introduction about functionalities of the tool. Nev- 5.4.1 Interviews’ Results
ertheless, during the design task, some of the participants Several threads run through the interviews. Such threads
were confused and hesitant about using some features be- are categorized as themes and reported subsequently.
ing provided by our tool. This was actually observable at
4
the beginning of the task, but seemed to be overcome later https://goo.gl/uwlwIp
5.4.1.1 Tool Usability 5.4.1.2 Informal and Formal Notation
There was a strong belief among the participants (12 people
Ease of Use. All participants pointed out that our tool is
agreed, 2 were undecided and 2 disagreed) that informal
intuitive, simple and easy to use.
notations (i.e. sketches) support the formal design. Sketches
“Easy to get started with, I do not have to under- can be used to interconnect different components
stand the UML-standard ”, “It’s simple to use”,
“define the components involved and the interac-
“Easy to change things”
tions among them”.
Learn-ability. The participants also stated that the tool is
Sketches are valuable artefacts beyond being just explorative
easy to understand and learn.
drawings
“easy to understand ”, “Easy to grasp what is what”, “obtain a formal document, not just a sketch”.
“Intuitive for the most part”, “So easy to learn”
There was also a strong belief among participants (11 peo-
Efficiency. We let our environment inherit the fluidity and ple agreed, 2 were undecided and 3 disagreed) that having
immediacy of a standard whiteboard. Furthermore, we wanted sketches beside the formal design can allow for a better ex-
to maintain the recognition process to be as smooth and fast pression of ideas
as possible. Some participants were impressed by the fluidity
and immediacy of our tool in drawing and creating notations “map out the domain of the functionality and
as well as in recognizing the sketchy elements. make sure everyhting is been covered ”, “get an
idea of how things fit together ”.
“Very quick to draw classes and associations com-
Eleven people claimed that sketches can enhance the under-
pared to CASE tools”, “Very smooth and quick
standability and readability of the formal designs
recognition”
“it is mostly for myself to get a clear understand-
Satisfaction. The basic functions of our tool met the expec- ing”, “it is helpful to make you understand what
tations of most of the participants. Overall, the participants you are gonna build ”
liked our tool. Two participant highlighted the eligibility of
our tool in collaborative team modelling. One participants On the other hand, one person said that having sketches
stated that he likes the “selective recognition” mechanism. beside the formal design could complicate the diagram
“Very straightforward once you get used to it”, “No, sketching will introduce complexity”.
“It is really good for team design”, “Nice that you
Half of the participants think that being able to sketch be-
select what to recognize”
side creating formal designs in one tool can replace the need
However, some challenges in tool usability were identified. of sketching on a whiteboard or a paper.
one participant asked for more flexible switching between
“Yes, you could perform all the functions that you
informal and formal input modes .
can do on standard whiteboard. Be able to quickly
“I did not like how I switch between input modes” show ideas, and you do not have to take pictures
of the whiteboard ”.
Some of the participants did not like the manner by which
the elements are being selected i.e. by activating a dedicated While some participants claim that still people will not stop
button. using standard whiteboards as well as pen and paper. The
dependency on such tools, as the participants argued, arises
“Should select by just clicking on element without from their immediacy and ease of use as well as being at
selecting the selection tool first” easy disposal.
One participant stated that “typing-in” classes name and “No, because you will never remove the paper from
their properties using the virtual keyboard was inconvenient offices”, “right now still very dependent on paper ”
task due to the time that it takes, and asked us to find a
better solution. Sketching down thoughts and ideas on paper or whiteboard
when designing software is a common behaviour when de-
“Typing-in is a bit slow ” signing software. In fact, all participants do sketches to some
degree. Some participants mentioned that it depends on the
We previously mentioned that our tool mainly supports UML complexity of the problem
class diagrams when creating formal “computer-drawn” ele-
ments. Some participants expressed the need of being able “I do not sketch when it comes to simple stuff ”.
to create other types of UML diagrams as well as having
more tool options. According to the participants’ responses, the main purposes
of sketching are to:
“I want more features, options, more types of di-
agrams” i) understand problems and start to explore solutions
We consider those challenges, hence they will be used to- “to define the components involved and the
gether with the overall feedback of the users as a basis for interactions among them”, “start putting the
future improvement of our tool. solution together ”
ii) brainstorm as well as explore ideas were appreciated by the participants and are discussed in the
conclusion and future work section.
“to brainstorm”, “to facilitate how to express
our ideas”, “to visualise what is in my head ”. • RQ.2 Does support for mixing informal and formal no-
tation better support the software design process?
iii) communicate and discuss their ideas
“give an explanation for other people about In practice, software systems are becoming more and more
the system or a specific problem”, “commu- complex, and the design of complex systems needs more ef-
nication of ideas in teams”. fort and hence more sophisticated designing tools. In such
cases, having the possibility to use informal notations be-
side the formal ones can better support designers’ activities
6. DISCUSSION in understanding the problems, exploring solutions, brain-
Before starting with the design task, the participants were storming and communicating ideas. This is in line with the
given a short introduction about our environment and its study of Mangano et al. [13]. They stated that informal no-
functions. However, while we were observing the partici- tations, i.e. sketches, allow software designers to discuss de-
pants creating their designs, we noticed that they were not sign alternatives as well as mentally simulate the behaviour
very inclined to use the sketching feature which was illus- of complex systems.
trated during the short introduction. In fact, only six (out Apart from the fact that our subjects did not sketch in-
of sixteen) participants used the sketching feature. We think formal elements frequently, the majority of them think that
that the time of the introduction part was most likely not being able to simultaneously create sketches and formal de-
enough to make the participants feel comfortable in using signs in one design environment could support the design
free-hand sketches. Furthermore, the design problem that process. Indeed, software designers often sketch their early-
we have chosen for the design task was simple and easy to design ideas on a paper. However, when they want to pre-
solve. We tried to simplify it as much as possible to make serve the design, they do a redundant work by re-drawing
it solvable in a short time. We believe that the simplicity the solution using CASE-tools. Furthermore, they may for-
of the design task could have defeated the need of sketching get to include some sketched ideas in the design formaliza-
it up. The participants could easily get a good grasp of the tion process.
design task simply by reading it. However when we did the There was a strong belief among the interviewees that hav-
interviews, the majority of the participants did agree that ing the possibility to create informal elements, i.e. sketches,
being able to mix informal and formal notations could sup- assists the process of ideas expression and enhance the un-
port the design process and flow, thus could bridge the gap derstandability of formal designs. The informal notations
between the process of prototyping ideas on a paper and the can be used both in brainstorming sessions and while cre-
process of entering a formalized version of such ideas in a ating the formal design. In the former case, they are used
CASE-tool. Next, we discuss the research questions based for design exploration and can be volatile. While in the
on our interpretation of the results. latter case, the informal elements could be used to sustain
and describe a specific design problem as well as support
• RQ.1 Does our tool provide a usable environment con- the formal design in conveying and reinforcing the informa-
sidering issues like ease of use, efficiency and user sat- tion that they carry. Informal sketches, for example, may
isfaction? have a very close mapping to the problem domain. As a
result, they could be valuable artefacts beyond being just
OctoUML is designed to offer a usable interactive envi- explorative means.
ronment. First we focused on understanding some common
practice activities that occur during software modelling ses-
sions. Then, we tried to consider and adopt some novel 7. THREATS TO VALIDITY
interaction modalities which could interactively support the Construct Validity. The design task was simple, specific
design process. The interviews’ results show that the cur- and easy to do. Moreover, it is relatively small compared to
rent version of our tool is easy to learn, effective to use, and real world design problems. This might limit the creativity
provides an enjoyable user experience. Moreover, the re- of the designers as well as influence the amount of discussions
sults that we got from the SUS questionnaire on the usabil- and usability interactions. However, during the interviews,
ity of our tool consolidate the previous findings. Of course we asked the participants to give their general opinion about
these results hold only for the device which is used as an the efficiency of our tool when it comes to handling different
input medium, the interactive whiteboard. Other media design problems that vary in size and complexity.
like tablets and standard PCs have different characteristics. Internal Validity. None of our subjects was familiar with
Tablets have a smaller interaction interface when compared our tool and its functions. To mitigate this, we gave the
to interactive whiteboards, and this could raise some usabil- participants a short introduction explaining the features of
ity challenges. To assess these challenges further tests on the tool. Moreover, during the interviews, the participants
different input media are required. On the other hand, our might want to please the interviewers by giving them a pos-
tests revealed some usability challenges related to our sys- itive feedback. To mitigate this, we asked the participants
tem. The main issue is the selection tool. The participants to answer the SUS questionnaire which allowed them to give
had to click on a specific button to activate the selection feedback anonymously.
mode. According to some participants, that was not a user- External Validity. The participants being involved in both
friendly choice. Moreover, we asked the participants for their the design task and the interviews may not represent the
opinion about some new interaction techniques that could be general population of software designers. This could threaten
adopted by our environment in the future. These techniques the generality of the results. However we involved people
with different backgrounds, modelling expertise and aca- [7] J. Corbin and A. Strauss. Basics of qualitative
demical degrees. research: Techniques and procedures for developing
grounded theory. Sage publications, 2014.
8. CONCLUSION AND FUTURE WORK [8] C. H. Damm, K. M. Hansen, and M. Thomsen. Tool
Currently, most CASE-tools are modelling (or even di- support for cooperative object-oriented design:
agramming) tools. Indeed, they lack support for the ma- gesture based modelling on an electronic whiteboard.
jority of design activities in which developers are engaged. In Proceedings of the SIGCHI conference on Human
In this paper, we presented a proof of concept of a new Factors in Computing Systems, pages 518–525. ACM,
generation software design environment. Basically, our tool 2000.
allows for simultaneous creation of both informal freehand [9] J. Iivari. Why are case tools not used?
sketches and formal computer-drawn notations. The users Communications of the ACM, 39(10):94–103, 1996.
of OctoUML can create software designs by performing sim- [10] R. Jolak, B. Vesin, and M. R. V. Chaudron. Octouml:
ple intuitive touch gestures. Moreover, they can manipulate An environment for exploratory and collaborative
the graphical entities with several fingers at the same time software design. In 39th Int. Conference on Software
thanks to the multi-touch technology being adopted by our Engineering. ICSE’17, page in print, 2017.
system. Furthermore, OctoUML supports the transforma- [11] M. Magin and S. Kopf. A collaborative multi-touch
tion of models from informal to formal at any time during uml design tool. Technical reports, 13, 2013.
the design sessions. We evaluated our tool by conducting [12] N. Mangano, T. D. LaToza, M. Petre, and A. van der
user studies. The results show that OctoUML, as perceived Hoek. Supporting informal design with interactive
by our subjects, provides a usable environment in terms of whiteboards. In Proceedings of the SIGCHI
ease of use, efficiency and user satisfaction. Moreover, it Conference on Human Factors in Computing Systems,
seems that giving the possibility to create informal and for- pages 331–340. ACM, 2014.
mal notations in one software design environment could sup- [13] N. Mangano, T. D. LaToza, M. Petre, and A. Van
port both the design process and its flow. Der Hoek. How software designers interact with
Future Work. We will continue to realize our vision [4] of sketches at the whiteboard. Software Engineering,
a new generation of software design environment. OctoUML IEEE Transactions on, 41(2):135–156, 2015.
will be equipped with microphones to record the spoken dis- [14] B. Paulson and T. Hammond. Paleosketch: accurate
cussions, and a recognition system will be provided to inter- primitive sketch recognition and beautification. In
pret users’ voice commands. To open up new opportunities Proceedings of the 13th international conference on
for remote interactive collaborative design, our tool will be Intelligent user interfaces, pages 1–10. ACM, 2008.
enabled to support remote collaborative sessions between [15] M. Petre. Uml in practice. In Proceedings of the 2013
geographically distributed teams as well as in class room International Conference on Software Engineering,
environment between students and teachers. We also aim pages 722–731. IEEE Press, 2013.
to integrate OctoUML with other software engineering tools [16] J. Sauro. A practical guide to the system usability
to provide effective support for different development tasks scale: Background, benchmarks & best practices.
(e.g. requirements gathering, testing, coding and version- Measuring Usability LLC, 2011.
ing) and analysis tasks (e.g. performance).
[17] T. S. Tullis and J. N. Stetson. A comparison of
questionnaires for assessing website usability. In
9. REFERENCES Usability Professional Association Conference, pages
[1] S. Baltes and S. Diehl. Sketches and diagrams in 1–12, 2004.
practice. In Proceedings of the 22nd ACM SIGSOFT [18] B. Tversky. What do sketches say about thinking. In
International Symposium on Foundations of Software 2002 AAAI Spring Symposium, Sketch Understanding
Engineering, pages 530–541. ACM, 2014. Workshop, Stanford University, AAAI Technical
[2] J. Brooke et al. Sus-a quick and dirty usability scale. Report SS-02-08, pages 148–151, 2002.
Usability evaluation in industry, 189(194):4–7, 1996. [19] B. Tversky. Visualizing thought. Topics in Cognitive
[3] M. R. Chaudron, W. Heijstek, and A. Nugroho. How Science, 3(3):499–535, 2011.
effective is uml modeling? Software & Systems [20] J. Walny, S. Carpendale, N. H. Riche, G. Venolia, and
Modeling, 11(4):571–580, 2012. P. Fawcett. Visual thinking in action: Visualizations
[4] M. R. Chaudron and R. Jolak. A vision on a new as used on whiteboards. Visualization and Computer
generation of software design environments. In First Graphics, IEEE Transactions on, 17(12):2508–2517,
Int. Workshop on Human Factors in Modeling 2011.
(HuFaMo 2015). CEUR-WS, pages 11–16, 2015. [21] J. Walny, J. Haber, M. Dörk, J. Sillito, and
[5] Q. Chen, J. Grundy, and J. Hosking. An e-whiteboard S. Carpendale. Follow that sketch: Lifecycles of
application to support early design-stage sketching of diagrams and sketches in software development. In
uml diagrams. In Human Centric Computing Visualizing Software for Understanding and Analysis
Languages and Environments, 2003. Proceedings. 2003 (VISSOFT), 2011 6th IEEE International Workshop
IEEE Symposium on, pages 219–226. IEEE, 2003. on, pages 1–8. IEEE, 2011.
[6] M. Cherubini, G. Venolia, R. DeLine, and A. J. Ko. [22] D. Wüest, N. Seyff, and M. Glinz. Flexisketch: A
Let’s go to the whiteboard: how and why software mobile sketching tool for software modeling. In Mobile
developers use drawings. In Proceedings of the SIGCHI Computing, Applications, and Services, pages 225–244.
conference on Human factors in computing systems, Springer, 2012.
pages 557–566. ACM, 2007.