PhilosophyAndVision

Introduction

The following are the key philosophies that govern the evolution of the Umple language and model-oriented programming technology. These are derived from those that first appeared in a paper published in WCRE 2010.

Elements of the Philosophy and Vision

In the following, L refers to a language such as Java, PHP or Ruby for which Umple can generate code.

P1. Modeling is programming and vice versa: UML concepts can be expressed textually in Umple; hence, one can model in UML using Umple. For a programmer, Umple looks like a programming language, therefore, to such a person they are just programming more abstractly.

P2. An Umple programmer should never need to edit generated code to accomplish any task. The need for round-tripping (editing generated code and then reflecting the edits back into the model) common in the Model Driven Engineering world is not needed.

P3. An Umple compiler can accept and generate code that uses nothing but UML abstractions. The resulting executable will be a module providing an API rather than a complete program, since it will initially lack a ‘main’ method and algorithmic methods. P3 is a corollary of P1.

P4. A program without Umple features can be compiled by an Umple compiler. This is the inverse of P3. In other words, any program P in base language L compiled by an Umple/L compiler will generate P. This provides a convenient starting point for a programmer who wants to begin using Umple incrementally: They can just change from using an L compiler to an Umple/L compiler.

P5. A programmer can incrementally add Umple features to an existing program. This allows for iterative conversion of a base-language L program into Umple/L, with each step being a straightforward refactoring. We call this process umplification.

P6. Umple extends the base language in a minimally invasive and safe way. A programmer familiar with language L should see the addition of an Umple feature as just a natural extension of L. In other words, Umple appears harmonious with L. As an example, for C-family languages this is accomplished by co-opting the curlybracket block idiom and adding a very small number of additional keywords. Another way of looking at this is that Umple can be seen as a pre-processor added to the base language, that uses a syntax that is very similar to the base language. This should eliminate or reduce any fear that adopting Umple should somehow mean learning a new language. Umple can be used in very small amounts if needed. And those fearful of what would happen if Umple were to 'go away' can rest assured that they would still have good quality generated code which could in this circumstance be modified.

P7. Umple features can be created and viewed diagrammatically or textually. One can use UML diagramming tools to generate an Umple program that contains only UML abstractions, as in P2. Similarly, since Umple features map directly to UML, one can easily render any Umple program as a UML diagram. This can be done in real-time; a web-enabled Umple editor that supports Umple textual code, as well as UML class visualizations. Elements of code that are not Umple abstractions, such as the bodies of methods, are omitted from the diagram.

P8. Umple goes beyond UML, since it directly implements patterns and other common programming idioms. Umple can, for example, generate code for the singleton pattern. Such capabilities further increase Umple’s level of abstraction.

P9. The base language code added to an Umple program corresponds to UML’s concept of an action language. To use UML for model-driven development, i.e. complete generation of an application from a UML model, UML calls for the use of an action language for the algorithmic details. UML diagrammatic modeling tools currently allow snippets of action language to be specified for elements such as state machine actions. Users of these tools have to switch between the visual editor for manipulating the modeling elements, and the textual editor for manipulating the action language snippets. This context switching from diagram to text makes it difficult to understand an entire program when using traditional UML tools.

Other relevant documents

• Best Practices for those using Umple to Model and Program
• Software Engineering Process to be used by Contributors to Umple