UML is the de facto standard for modeling software designs and is commonly used in commercial software development. However, little is known about the use of UML in Open-source Software Development. This paper evaluates the usage of UML modeling in ten opensource projects selected from common open-source repositories. We evaluated the usage of UML diagrams based on the information available in the open-source projects repositories. Our study covers the types of UML diagrams that are used and how frequently UML models are updated. Our ndings also include the change in focus on types of diagram used over time and researches on how the size of models relates to the size of the implementation.
UML provides the facility for software engineers to specify, construct,
visualize and document the artifacts of a software-intensive system and to facilitate
communication of ideas [
One of the bene ts of UML is to ease communication between software developers. The nature of OSSD is that software developers normally communicate with each other using some online communication medium (e.g discussion forum, e-mail, IRC) rather than through physical interaction. There is an anecdotal belief that UML is rarely used in OSSD. However, there is no quantitative research to prove this perception. In this paper, we aim at evaluating the usage of UML diagrams in OSSD projects. We want to discover how UML is used in OSSD without the in uence of the stakeholders or users of the system. We explore the publicly software documentation to answer the following questions: 1) What types of UML diagrams are used? 2) How does the size of the design relates to the size of the implementation? and 3) How does timing of changes in the implementation relate to changes in UML diagrams/documentation?
The paper is structured as follows: Section 2 discusses related work. Section 3 describes the case studies used in this research. Section 4 describes the study approach while Section 5 presents the results and ndings. This is followed by our conclusion and future work in Section 6. 2
Dobing and Parsons [
Grossman et. al [
Yatani et. al [
Most of the related works use surveys to discover the usage of UML
diagram. These surveys are based on the UML practitioners' perspective of how
they use UML. In contrast, our study evaluates the use of UML modeling in
OSSD projects by mining the project documentation. Hence, this re ects the
real artifacts produced by using the UML notation.
Based on researches by Hutchinson et. al [
The source code should be written in Java Projects that are developed in Java is selected because we need to reverse engineer the source code to class diagram for analysis purposes. The reverse engineering tools that we used for this study performs best with Java source codes. We found ten software projects which are suitable that are listed in Table 1. 4
This section describes the approach we used in this study. We had three main activities in order to answer the following research questions : RQ1 : What types of UML diagrams are used? Based on the project repository, we manually browsed the documentation and other provided information to nd all the UML diagrams that were used in the project.
RQ2 : How does the size of the design relate to the size of the implementation? Our aim was to use one single tool for counting classes of both the design and implementation. Furthermore, for source code, we only wanted to count classes that were actually designed for the project's system, hence to exclude library classes that are imported, and would typically not be modeled. To this end, source codes were reverse engineered using several Computer Aided Software Engineering (CASE) tools i.e MagicDraw 17.03 and Enterprise Architect 7.54. The reverse engineered design was then exported to XML Metadata Interchange (XMI) les. From the resulting XMI les, software design metrics were computed using the SDMetrics 5 tool and all library classes were removed. RQ3 : How does timing of changes in the implementation relates to changes in UML diagrams/documentation? For source code, we manually extracted the dates of releases from the project repositories. For UML diagrams, we looked at the date-information provided by the system documentation, developer's manual and other related documents in the project repository. 5
In this section, we present the results. We group our results into the three questions presented in the previous section. 5.1
Usage of UML Diagrams
The UML diagram that was mostly used in our set of open-source projects is
the class diagram. This is to be expected because our main keyword of searching
3 http://www.nomagic.com/
4 http://www.sparxsystems.com.au/
5 http://www.SDMetrics.com/
for case study was based on class diagrams. Table 2 shows which other types
of diagrams were used. The term `yes' in Table 2 means that the project used
at least one instance of a UML diagram speci ed in the table. The use of UML
in OSSD projects seems driven by a need to codify high level knowledge. For
example, ArgoUML did not use sequence diagrams in their modeling until there
was a new feature. Only this new feature was explained by a sequence diagram.
In general, the case studies show that the most used UML diagrams in OSSD are
use case, component, package, class, sequence/interaction and activity diagram.
The following subsections describe the results in more detail.
Use Case Diagram. Use case diagrams were used by only one OSSD project:
JPMC (see Table 2). A use case diagram is used to describe the desired
functionality of the software product [
Component Diagram. Component diagrams are used to divide the system
into components and show their interrelationships through the breakdown of
components into a lower-level structure [
Package Diagram. Package diagrams provide a grouping construct that
allows to group design elements together into higher-level units [
Class Diagram. Class diagram is the most used diagram type in these case studies. Most of the case studies only show classes that are important in the system. The correspondence between classes and implementation is discussed in section 5.2.
Sequence/Interaction Diagram. Sequence diagrams were used by two OSSD projects. However, both projects have only one sequence diagram per project. ArgoUML introduced a sequence diagram after eight version releases. Table 4 shows that only after version 0.26, a sequence diagram was introduced in the documentation. Perhaps, it is di cult to construct the sequence diagram for the entire release hence, the developer of this project used sequence diagram for a new feature. The gwt-portlets project used only one sequence diagram. We assume that the described ow contains crucial information for the system because the classes that were involved in the sequence diagram were presented in a class diagram that shows the key classes of the system.
Activity Diagram. Activity diagramming or activity modeling emphasizes the
ow and conditions for coordinating lower-level behaviours [
45.00 n ig40.00 s e D m35.00 n i sm30.00 e s s a lC25.00 m f o20.00 m e g ta15.00 n e c re10.00 P 5.00 This subsection presents the frequency of updating the UML models of the case studies. We would like to know whether UML diagram is used throughout the projects or only in initial phases. We analysed the case studies that have multiple versions of releases to assess the frequency of updating the diagrams while the systems evolve through subsequent releases. Even though there were multiple versions of system releases for the Mars Simulation, JavaClient, JPMC, Gwt-Portlet, Maze and xUML-compiler project, their UML diagrams were not changed. For instance, the Mars Simulation project has released 26 versions of source code. The UML designs were only uploaded in Dec 2009. Based on that date, we assume that this design corresponds with this release version 2.87 and above. This indicates that the earlier 19 versions of the software did not have a UML model. However, we could not disregard the fact that the design may be created earlier than the date it was uploaded.
The result also shows that the frequency of updating UML diagram is low. In
most of the case studies, a new UML diagram is created when there is a new
feature of the system introduced in a new version or release. Only the Neuroph and
ArgoUML project actually modi ed existing diagrams. Other project only added
new diagrams to their documentation, but did not modify previously existing
diagrams. In the ArgoUML project, we found that there was an increasing amount
of diagrams at the same time as the number of project contributors increases.
The work by Wen Zhang et. al [
Next, we discuss the ArgoUML project as an example of a project that did update their UML designs across multiple versions of releases. Table 4 shows which types of diagrams were used across subsequent versions over time. The table shows in early stages of development, diagrams were made that represent the high level structure of the system (component, package and class). As development time progresses, diagrams are added that represent the dynamic behaviour of the system through activity diagrams (v 0.16) and sequence diagrams (v 0.26). Also, at the later stages of development, component diagrams are no longer used. We believe this trend to be typical of the use of modeling in software development in general : Firstly, the developers design the overall structure and later continue to esh out behavioural aspects of the design. Figure 2 shows the evolution of UML Diagrams in every versions of release. Figure 2 also shows the evolution of the number of classes. It is explicitly shown that the UML diagrams are created in the early stage of software release and then updated occasionally. This section describes the threats to validity of this study. In term of case study selection, there could be more case studies if we included more open-source repository. The selected projects may not represent all the OSSD because the selected case studies can be considered as small and medium type of system development. In addition, we also did not have projects with the number of classes between 250 and 800. The result could be di erent if more larger projects would be included in this study. The study was done based only on using the information in the project repositories and also the projects websites. It may be the case that developers use UML in their communication or for internal use without uploading their diagrams in the project repository. This study also only used the date listed as the upload-date of the documents in the repositories. The document may be created far before the uploaded date. Thus, the matching of the date of documentation and the version may not be accurate. 6
This study aims to discover the usage of UML diagram in the OSSD projects. To this end, ten case studies were collected from online repositories. Three main questions were studied: What types of UML diagrams are used?, How does the size of the design relates to the size of the implementation? and How does timing of changes in the implementation relate to changes in UML diagrams/documentation? By studying the evolution of UML models across versions, we found that the focus of modeling shifts from structural aspects in the early phases of development, to dynamic behaviour in the later stages of development. The frequency of updating UML models is low. We found two triggers for updating UML diagrams: 1) if there are changes in the features of the system, and 2) if there is a group of newcomers joining the project. The latter cause con rms the role of UML models as a way of codifying design knowledge for communicating the design. Overall, this paper shows that open-source projects can be used as empirical source for studying usage of UML modeling.
For future work, it would be interesting to extend this study by performing a broader survey or interview OSSD developers to nd out the reasons for or against using UML diagrams in their development. Also, it is interesting to ask developers after their pattern in updating UML models. Finding more case studies and extending the case studies to languages other than Java. This would allow to di erentiate results between programming languages.