Umple: Bridging the Code-Model Divide

1 Umple: Bridging the Code-Model Divide Timothy C. Lethbridge, Andrew Forward, Dusan Brestovansky School of Information Technology and Engineering, University of Ottawa {tcl,aforward}@site.uottawa.ca, [email protected] Abstract Finally, we present some case studies that demonstrate the value of the Umple approach. We present an approach to object-oriented software engineering intended to reduce the ever-present 2. Motivations tension between model-centric and code-centric developers. The former prefer to model visually and Our desire to develop Umple arose for two main generate code, while the latter see source code as the reasons. We address each of these in the following only important software artifact. The core of the subsections. Together, these motivations naturally led Umple approach is to add UML abstractions such as us to want to develop Umple. associations directly into a high-level programming language – our current implementation works with 2.1 Prevalence of the code-centric approach in Java. With Umple, the developer can work software engineering: Lack of adoption of interchangeably with UML diagrams and Umple code; modeling these are just views of the same thing. We describe the basics of Umple as well as the tools used to work with Many software engineering researchers and opinion it; these include plugins for Eclipse and Rational leaders describe what they see as the obvious benefits Software Modeler. To demonstrate the benefits of the of modeling. Principal among these is enabling approach, we present as case studies a few systems we developers to work at a higher level of abstraction [1]. have developed in Umple, in particular the functional However, when one interacts with developers in real layers of airline reservation, elevator control and companies, is clear that the overwhelming majority of timesheet management systems. developers see source code as their primary work medium, Most of them will draw diagrams when 1. Introduction explaining concepts in design meetings, and include some of them in design documents, but relatively few In this paper, we present Umple. Umple can be use models to actually drive development. This is viewed from several perspectives. It can be seen as a particularly true in the agile and open source programming language based on Java that incorporates communities [2]. UML constructs to raise the level of abstraction. It can be viewed as a tool for rapidly creating UML 2.1.1 A brief literature survey: There has been some diagrams. Or it can be viewed as a tool to help broaden research into why modeling is not more the appeal of modeling by allowing models to be enthusiastically adopted. Afonso et al [3] state that created textually. In fact, it is all three of these. although modeling is standard in the database design In the next section we discuss our motivations for community (where use of Entity Relationship developing Umple. These include the lack of adoption Diagrams is the norm), “there is little practical of modeling technology caused in part by difficulties evidence of the impact” of model-driven approaches using modeling tools, and a desire to reduce the among the broader software engineering community. amount of code needed in certain object-oriented There are clearly a number of common obstacles to programming tasks. modeling. Berenbach et al [4] suggest that these Then we present various aspects of Umple: These include a belief among developers that modeling is include the overall philosophy, the concrete syntax, an only about drawing “pretty pictures”, and not overview of the semantics and the tools we have understanding well enough how to model in the developed. prevalent object-oriented paradigm. 2 Modeling is seemingly particularly important for subsequent manual manipulation. c) Model-as-design- safety-critical systems. Anda et al. [5] studied aid: Approaches where modeling is done for design practitioners in this domain and note that they had purposes, but then code is written mostly by hand. d) good results when they adopted a more model-oriented Model-as-documentation: Approaches where modeling approach. Difficulties using modeling tools and the is done to outline or describe the system, largely after costs of training were the biggest obstacles. Another the code is written; and e) Code-centric: Approaches obstacle was tendency of management to remain be where modeling is almost entirely absent. oriented towards the production of source code. The respondents in our study felt that for corrective The Object Management Group is the main industry maintenance and developing efficient software the association interested in promoting modeling. They code-centric end of the spectrum would be better, supported Dobing and Parsons [6] in a survey in which however, they agreed that for almost all other tasks, 171 practitioners were asked how they use UML in including new development, adaptive maintenance, and practice. Most respondents felt that UML is indeed program comprehension, model-centric approaches useful in software development, but half the said they work best. did not fully understand class diagrams. The study The respondents had three main criticisms of the concluded that complexity of UML is one of the main model centric approach: 68% felt that it is a bad or obstacles to its use. terrible problem that models become out of date or One issue to consider is whether performing inconsistent with the code; 52% complained about modeling has sufficient return on investment. Arisholm incompatibility among tools, and 39% complained et al. [7] concluded from a controlled study that the about tools being too heavyweight. costs of maintaining UML documentation may On the other hand the respondents also had sometimes outweigh the benefits of modeling. complaints about code-centric approaches: Two thirds Another issue is the usability of modeling tools. complained about difficulties understanding the design Agerwal et al, [8], [9] studied this issue and found that or behaviour of the system based on code, and over poor usability contributes to higher than necessary half complained about code being difficult to change in costs associated with modeling. general, as compared to models. Adoption is, of course, an issue with many tools and technologies. Sultan and Chan [10] provide and in- 2.1.3 Personal experiences. We do a considerable depth discussion of object-oriented technology amount of modeling and would like to be able to adoption. They conclude that lack of adoption is likely generate and modify UML diagrams very rapidly. not due to intrinsic weaknesses in the technology, but Whether it be for teaching UML, illustrating books or has more to do with culture and management. papers, or developing actual systems, we have found both the commercial and open source tools slower at 2.1.2 Our own study of participants: We modeling than we would like. conducted our own study [11] of 113 software developers in a wide variety of industries and 2.1.4 Summary and links to Umple. We conclude countries. We received responses that seem more from the above that the reasons for lack of more positive that what is reported in the literature cited wholehearted adoption of modeling seem to be as above. follows: Well over half of our respondents do in fact perform a) Code generation doesn’t work as well as it needs some type of modeling, with about 52% using UML to; often or always. Sixty percent use visual notations to b) Modeling tools are too difficult to use; document their code prior to design, although only a c) A culture of coding prevails and is hard to third always do this. However, only 17.5% often or overcome; always generate code from models and 36.5% never do d) There is a lack of understanding of modeling this. Most of the value of models is therefore to notations and technologies; document and communicate designs. Eighty percent in e) The code-centric approach works well enough, fact said that modeling tools are poor or awful at the such that the return on investment of changing is task of generating all the code for a system. marginal, yet the risks high. We presented the respondents with a list The Umple approach addresses all these reasons. development styles as follows a) Model-only: Point a) is addressed by the fact that Umple is a Approaches where the model is effectively all there is, programming language, and a simple one. One of the except for small amounts of code. b) Model-centric: main difficulties in generating code from a language Approaches where modeling is performed first and like UML is that the semantics of UML were in fact code is generated from the model, for possible explicitly designed to be for abstract modeling – it is 3 difficult to translate a model into code. Umple adopts specification [14], or one of the many books on the key modeling features, but in its design we have subject. e.g. [13]. chosen to err on the side of making it simple and Ultimately, however, association abstractions still usable for programming. It adopts Java semantics have to be rendered into programming language code. when these differ from UML semantics. Unless one can use a UML tool that can generate Umple addresses point b) by allowing modeling to the code for you, the first thing you need to do is to be done using a simple text editor. Umple has a Java- declare instance variables. In Java and other OO like syntax so a syntax-directed editor can be used to languages, the class opposite a ‘1’ or ‘0..1’ help produce error-free code or models. At the same bidirectional association end would typically contain time, however, the Umple tools provide the capability an instance variable with its type declared to be the to rendering Umple code as UML diagrams directly in other class.

Load more