Modeling Practices in Open Source Software OSS 2013 Koper-Capodistria, Slovenia Omar Badreddin Post Doctoral Fellow, University of Ottawa Tim Lethbridge Professor, University of Ottawa Maged Elaasar (Presenter) Senior Software Engineer, IBM

2 Status of Modeling in OSS  Code is king!  Models are hardly used if ever  Main use of models is for documentation  No significant Model Driven Development (MDD)

3 Related Studies and Surveys  Livari (1996): After a year  70% of modeling tools are no longer used  Only 5% are widely used (despite positive impact reported)  Robbins (2005): open source developers rarely use modeling tools  lack of pressure to have rigor or follow deadlines  Ohloh.net (2003): 0.3% of OSS projects are model based

4 Reasons for Low Adoption of Modeling in Open Source  Culture of ‘code is king’ prevails and is hard to overcome  Modeling languages are too complex  Graphical notation (diagrams) hampers productivity  Modeling tools are hard to use and perceived as heavy weight  Modeling tools are silos and do not interoperate with other tools  Code generation is of poor quality and hard to customize  Model-code-model round-tripping does not work well

5 Proposed Solution: Model Oriented Programming  Modeling abstractions are embedded textually with code  Extend the textual syntax of a programming language (Java, C++, …)  Map textual syntax to graphical syntax on the fly (generate diagram)  Continue to use the existing text-based development tools  Development IDEs  SCM systems  Builds scripts  Continuous delivery

6 Umple: Simple, Ample, UML Programming Language  Textual model-oriented programming technology  Extends Java, C++, PHP, Ruby, etc.  Supports UML Class and state-chart modeling  Supports patterns, mixins, aspects, concurrency, constraints  Well suited for open source development  UmpleOnline [ ]  Command line compiler  Eclipse development environment

7 Umple Example – Class Diagram

8 Umple Example – State-chart Diagram

9 Umple Philosophy  Modeling is programming and vice versa  Umple source can be code only, model only or a mix  Intermediate generated code should not be edited  Umple extends a base language in a minimally invasive way  Umple features can be created and viewed diagrammatically or textually  Umplification: incremental use of Umple features in code

10 Recommended Uses of Umple for Open Source Development  Umplification  Incrementally replace boilerplate code with modeling abstractions  Lightweight Modeling and Analysis  Visualize Umple source as UML diagrams to analyze it  Model driven development  Generate code in one of the supported base languages

11 Case Study: Umple as an Open Source Project  An open source project (5+ years)  Hosted on Google Code repository since 2010  Average of 10 active developers  Developed using the Umple extension for Java  Eclipse (+ command line if desired)  SVN (Moving to GIT soon)  Text compare features  Continuous integration server with automatic tests

12 Quantitative Assessment of Umple Development  Analyzed 3 Umple artifacts that started as Java then got umplified over time  Artifacts have different distributions of Java vs. model abstractions

13 Model Changes Trend Over Time  Question: how do model changes trend over time?  Umple source experienced umplification (more model content) over time  Expected to see upward trend in model changes that would persist  Observed initial spike (umplification) then downward trend of model changes Model changes trend over time

14 How does Model vs. Code Change Relative to Its Size  Question: which parts of Umple source are more prone to change?  Model changes were inline but slightly less relative to model size

15 Conclusions and Future Work  Adoption of modeling in OSS is low  We provided some reasons that would explain that  Solution: model oriented programming (Umple)  Modeling needs to be textual and supported in a non intrusive way  Umple is developed using itself  Benefits of using Umple in OSS  Lower code volume to maintain  Code that is less prone to change over time  Future work  More studies on impact of umple on development  Improved tools  Automated umplification  Extensions to Umple (e.g. Real time)  More info on Umple:

16