UML is a large notation o ering many diagrams and a large set of constructs for each of them covering any possible modelling need. As a result its speci cation is a huge book, its metamodel is large, and de ning/understanding its static and dynamic semantics is di cult. These features have a negative impact on the perception of the UML and lead in some cases to replace it by ad-hoc lean and simple DSLs. Thus, the following question arises: which are the most/less used UML diagrams/constructs? We would like to answer to this question by means of a survey, trying to detect which parts of the UML are the most used. To see how much a diagram is used we preliminarily investigate books, courses/tutorials, and tools covering UML. The less used diagrams will be then analysed to understand the reasons of their low usage.
UML is a truly large notation o ering many di erent diagrams (14 in the last
approved version [
On the other hand, users naturally tend to consider and use only a portion
of its diagrams/constructs, and forgetting about some other ones. On his blog
I. Jacobson states \For 80% of all software only 20% of UML is needed" [
We would like to asses by means of a survey which parts of the UML
(diagrams and constructs) are the most used in practice and which the less ones,
using again the words of Jacobson trying to see if an \essential UML" [
For a given UML diagram, we have proceeded as follows. We have investigated the books to discover if they were citing such diagram, and if they were giving an example of it. Similarly for the courses/tutorials, whereas for the tools we have tried to produce a model containing such diagram. Finally, we have computed descriptive statistics to present the results.
The results of this survey, of which this work constitutes the rst step, and of the future personal opinion survey should be of help to many di erent categories of people: { teachers and instructors: allowing to o er courses and/or tutorials concentrating only a smaller language made out of the most used UML diagrams/constructs; { tool builders/users: obvious advantages since the tools covering the most used diagrams/constructs will be simpler to implement/use. { notation designers: interested in discovering scarcely used constructs, and understanding for which reasons they have been added to the language. Moreover, other interesting questions arise: are the scarcely used constructs derived1 or primitive? can the scarcely used constructs be applied only in speci c cases? It will be interesting to investigate whether the metamodel (and subsequently the UML speci cation book) may be easily simpli ed to cover only the most used constructs.
In our opinion having to handle a notation with a large set of constructs
where a portion of them are scarcely used, if not almost unknown, is
problematic because it can cause a waste of e ort and of resources by who want/must
use it (e.g., in Italy, some contracts with the public administration must be
accompanied by a UML model). From the trivial fact that to print the reference
requires 700 sheets, to the fact that understanding the metamodel/preparing for
the certi cation/deciding what to teach to the students/reading a UML book
require a large number of hours, and we do not have to forget that also
maintaining the o cial speci cation and any related item requires a large amount of
e ort due to its size. Also the OMG has recently recognised the need to simplify
1 A derived construct may be replaced by a combination of other constructs.
the UML with the initiative \UML Simpli cation" [
In this paper we present the results of the rst step of our survey, i.e., focusing on the usage level of the 14 types of UML diagrams and covering books, courses/ tutorials, and tools. The remainder of the paper is organized as follows. In Sect. 2, we present related work literature regarding empirical study about the UML. In Sect. 3, we sketch the relevant aspects of the conducted empirical work such as: goals, research questions, followed process and analysis methodology. The results of the survey are presented in Sect. 4, while threats to validity are discussed in Sect. 5. Finally, Sect. 6 concludes the paper. 2
The systematic literature review (SLR) by Mohagheghi et al. [
In the tentative to nd the \essential UML", Erickson and Siau [
blogs.msdn.com/b/sonuarora/archive/2009/11/02/simplify-uml.aspx 3 It attempts to form a reliable consensus of a group of experts in specialized areas.
The main conclusions from another SLR by Budgen et al. [
The instrument we selected to take a snapshot of the state of the practice
concerning UML usage is that of a survey. In the survey's design and execution
phases we followed as much as possible the guidelines provided in [
The survey has been conducted through the following steps: (1) goals selection, (2) goals transformation into research questions, (3) identi cation of the population, sample and process, (4) data extraction and, (5) analysis of results and packaging.
We conceived and designed the survey with the goal of understanding which are the less/most used parts of the UML in practice. Within the scope of this work, in this paper we aim at addressing the main research question related to the above described goal:
Which of the 14 types of UML diagrams are the most/less used in practice? The rst step to conduct a survey is de ning a target population. The target population of our study consists of sources concerning UML. In particular, in this study we considered the following four kinds of sources: books, tools, courses and tutorials.
To sample the population and select the sources to consider in our study
we: (1) conducted a systematic search performed using Internet resources, Web
search engines and electronic databases and (2) used non-probabilistic
(convenience sampling) methods [
After having collected the sources, we extracted the data of interest for our research questions and nally we performed the analysis. Given the nature of this survey, that is mainly descriptive (it describes some condition or factor found in a population in terms of its frequency and impact) and exploratory, we mainly applied descriptive statistics and showed our ndings by means of charts. 3.1
The inclusion/exclusion criteria can be common for all the kind of sources or speci c. For all the sources we adopted the following inclusion criterion: only sources concerning UML versions 2.0. Concerning books, in case of di erent editions of the same book we opted (when possible) for the last one. Moreover, we excluded elements of \grey" literature, i.e., books without ISBN. Concerning tools, we included only UML modelling tools (both commercial and non-commercial) and excluded: (1) general graphics editor (e.g., Inkscape), (2) tools providing only a speci c type of diagram (e.g., class diagrams), (3) really unstable, not complete or preliminary tools (e.g., tools in beta version). About courses, we considered only university courses concerning IT studies. We considered courses o ered also in languages di erent from English (e.g., Italian and Spanish). Concerning tutorials, we considered only tutorials provided on Internet as written documents (either on-line or downloadable) and video (where a person gives instructions on how to do something) but we have excluded tutorials taking the form of a screen recording (screencast) and interactive tutorial. For selecting a document of this kind we used the common meaning/perception of tutorials: a tutorial is more interactive and speci c than a book or a lecture; a tutorial seeks to teach by example. 3.2
The process followed to conduct a survey should be as much as possible well de ned in order to ensure that such a study be objective and repeatable. For each category of sources, we followed a di erent process to collect the sources.
Books. We started by the Amazon website4 and used the search form to
nd UML related books. We selected the \Computers & Technology" category
in the books section. Then, we experimented with several di erent search
criteria using di erent combinations of strings. Finally, the one that retrieved the
highest number of useful items was the simple string \UML 2". Starting from
this long list of books ordered by relevance5 we ltered out books not satisfying
the inclusion criteria explained above. Then, we tried to recover them using the
facilities provided by our library. Finally, we collected and analysed 30 books.
Note that, 18 of them are in the top 24 books ranked ordering the list by
relevance by Amazon. The complete list of books is not reported here for space
reason and can be found on the online technical report [
Tools. We started by the \List of Uni ed Modeling Language tools" Wikipedia
page6 containing 49 UML tools. Then, we considered also the UML-tools
website7. A full Internet search was also carried out using Google. Also in this case,
we experimented with several di erent search criteria using di erent
combinations of strings to provide to Google (\UML tools", \UML tools list" and \UML
free tools"). For each tool of our list, we found the o cial website and selected
only the tools satisfying the inclusion criteria explained above. Then, we
downloaded and installed the most recent version of all the selected tools. In case
4 http://www.amazon.com
5 2.726 books on July 20, 2013.
6 http://en.wikipedia.org/wiki/List of Unified Modeling Language tools
7 http://www.uml-tools.com
of commercial tools, we selected a \free for not commercial use" version or a
version with university licence or a trial version. At the end, we collected and
analysed 20 di erent tools. The complete list of tools is not reported here for
space reason and can be found on the online technical report [
Courses. We started carrying out a search using Google. The
combinations of strings used were: \UML course", \UML lecture" and \UML
university course". We found several university courses satisfying the inclusion criteria
stated above, but in several cases it was di cult, if not impossible, to recover
the slides of the lectures, and in general the material. Often, the material was
not publicly available; only the content of the lessons was present on the website.
For this reason, we resort also to convenience sampling, asking to our colleagues
the slides of UML courses they teach. At the end, we collected and analysed 22
di erent University courses. The complete list of lectures is not reported here for
space reason and can be found on the online technical report [
Tutorials. We started with the tutorials lists present in the following three
websites: www.uml.org8, stackover ow.com9 and www.jeckle.de10. Then, we
integrated the obtained results with other tutorials recovered using Google (the
research was conducted using the strings: \UML tutorials" and \UML guide").
Finally, we collected and analysed 18 tutorials. The complete list of tutorials
is not reported here for space reason and can be found on the online technical
report [
We preliminarily decided to interpret the results of our survey assuming that a diagram is widely used if it is present in the 60% of the sources, similarly it is scarcely used if it is present in 40% of the sources, having also some nonde ned cases (grey zone). In the following subsections we present the results concerning UML diagrams.
The level of usage of the various UML diagrams in books, courses, tutorials, tools, and in the totality of the sources respectively is summarized in Fig. 1. If we consider the totality of the sources, disregarding their kind, we have that the scarcely used diagrams are timing, interaction overview and pro le, listed starting from the most used; all of them were not present in UML 1.x, and the pro le diagram appeared only in version 2.2. The last position of the pro le
diagram is not very surprising due both to the late appearance and to the fact that this kind of diagram has a very restrict scope (indeed it is used only to present a pro le) and that, it is essentially a variant of the package diagram. Also timing diagrams, see an example in Fig. 2, have a restrict scope, and UML o ers other ways to model time related aspects (e.g., timed events may be used in state machines and activity diagrams; durations and time intervals may appear in sequence diagrams), and this may be the motivation for their low usage. Finally, interaction overview diagrams are quite complex and in many cases may be replaced by sequence diagrams and/or a combination of sequence and activity diagrams, and perhaps this is the reason for not being so considered.
The widely used diagrams, when considering the totality of the sources, are
instead, listed again starting from the most used ones, class (100% in any kind
of sources), activity, sequence, state machine and use cases, communication,
deployment, component, object and package diagrams. The rst position of class
diagrams is not surprising, it is indeed the fundamental diagram of the UML,
while the fact that activity diagrams are the second is relevant and is due, in our
opinion, to the fact that they are used also for business process modelling and for
SOA based systems. All the widely used diagrams, except the package diagram,
were already present in the UML 1.x versions (also if the communication
diagrams were before called collaboration diagrams). The only diagram in the grey
area (i.e., above 40% and below 60%) is the composite structure, that allows to
represent both structured classes and collaborations; again it is a new diagram
appearing in the UML 2.0 and this may be a reason for its low usage.
However, the result is surprising because structured classes were completely absent
in UML 1.x, and this was a perceived problem, and the new collaborations are
truly useful (see for example the big role that they have in representing service
oriented architectures in the SoaML OMG standard pro le [
The results are di erent, see Fig. 1, if we distinguish the various kind of sources. In the case of books we have considered two kinds of books: 15 UML guides (Book Guide) and 15 books that make usage of UML but where it is not the primary subject (Book Spec). In the case of the UML guides, all diagrams except the pro le diagrams are widely used. This result may perhaps be due to the fact that we count as present in a book a diagram also if it is only mentioned. Unfortunately, it is really di cult to devise a better metrics; for example trying to distinguish if a diagram is just mentioned, shortly presented, presented, or presented with all the details may to be too much depending on the personal judgement of who examines the books; also counting the occurrence of the name of a construct/diagram is in our opinion too dependent on the way the books were written, e.g., more or less verbose. We have also tried to distinguish the case of a simple mention of a construct in the text and the presence of an example of such construct, without detecting a relevant di erence. Similar results, even if slightly reduced in magnitude, came from the other category of books (Book Spec).
For the tools the only scarcely used diagrams, see Fig. 1, are timing and pro le diagrams, whereas the interaction overview diagram is the only one in the grey area. This result is a little surprising, since one can expect that due to the e ort required to add a feature to a tool, the less relevant diagrams are omitted in many cases. In our opinion, since once you have available the functionalities to draw a class diagram it is quite easy to add the possibility to handle composite structure, component, deployment, object, package, communication and pro le diagrams, whereas timing and overview requires new graphical functionalities.
Considering only the courses, we have a striking distinction between the diagrams; indeed, class, sequence, activity, state machine and use case diagrams are widely used with percentage over 90%, component diagram, deployment, object package, communication are in the grey area (all above or equal to 50%), whereas composite structure (14%), interaction overview (5%) and timing (5%) are really scarcely used. A lecturer preparing in a course has to decide which are the most relevant diagrams to present to the students in the allowed time slots, and it seems that this decision is quite homogeneous: there are ve fundamental diagrams in the UML for the lecturers (class, sequence, activity, state machine and use case).
For the tutorials, we have a neat distinction between the widely used diagrams (class, activity, component, deployment, sequence, communication, use case and state machine) and the scarcely used (composite structure, timing, interaction overview and pro le diagrams), but the di erences in the usage level are lower than for courses, e.g., composite structure, timing, interaction overview percentages are more than 25%. In this case the tutorial writer has to decide what is relevant, but s(he) usually has no strong constraints on the size of the tutorial itself. 5
To avoid to bias the results of our survey, we have considered only sources concerned with the use of the UML, avoiding those with di erent aims, for example drawing tools suitable to produce pictures of UML diagrams, or books presenting a survey on the current visual notations have been excluded; whereas instead books covering speci c use of the UML or courses about software engineering where the UML was taught were included.
For the tools, instead, we are quite con dent to have examined almost all the available ones; we think that a UML tool cannot exist without being presented somewhere on the Web. Notice that Argo UML, one of the most known UML tool was not included in our survey since it does support only UML 1.x.
We have considered here only four kinds of sources (books, courses, tutorials, sources) and we are aware that these are not the only ones; indeed there are also the UML users, and we are ready to launch a personal survey to investigate which constructs they know and which they use.
Finally, we have decided to de ne widely used (scarcely used) when a diagram was considered in the 60% ( 40%) of the sources, resulting also in a grey area. We think that this a sensible choice, using a threshold lower than 60%, e.g., 50%, should have led to have that a construct is either widely used or scarcely used without any doubt cases, and this does not sounds realistic. On the other hand, a higher threshold, e.g., 80%, should have led to a quite large number of inconclusive cases. We have also computed the widely/scarcely used on the totality of the sources, disregarding the fact that they are of very di erent kinds, e.g. books and courses, and so assigning to them di erent weights would have been more realistic. Again, we had the problem to compute these weighs in an unbiased way: is it sensible to say that a book is three times more relevant than a course, or that a tool is two times more relevant than a tutorial? To avoid to make our result too dependent on our personal judgement we have preferred to assume that all the sources have the same weight. 6
We have investigated, by means of a survey, how much the UML diagrams are used, considering in this paper four kinds of sources: books, tools, courses, and tutorials concerning the UML itself. The results of our survey show that the usage of the various diagrams is di erent . An \essential" UML seems to emerge also if its boundaries are not exactly de ned. For what concerns the diagrams, class, activity, sequence, use case and state machine diagrams are widely used without any doubts, whereas interaction overview, timing and pro le diagrams are really scarcely used.
In this paper we have considered only \objective" sources and examined them for checking if UML diagrams are used in an objective way (e.g., can a tool produce a model including such diagrams?, is a course/tutorial teaching the fact that UML has such diagrams?), so these results are not biased by any personal opinion (neither ours nor of any human being taking part in the examination of the sources). We are now investigating the usage of the constructs used in the UML diagrams and launching a personal survey to investigate which UML diagram/constructs are known and used by UML users trying to cover di erent categories of them, and di erent applicative elds. The combined results of the two surveys should lead to nally determine an \essential" UML.