Umple 
User Manual [Previous] [Next]
Philosophy
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 programming language such as Java, Python, PHP or Ruby for which Umple can generate code, or which can be embedded in Umple.
Also in the following, Modeling refers to representing programs at a higher level of abstraction than in a programming language, either textually or with diagrams.
P1. Modeling is programming and vice versa: UML and other modeling 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) is avoided.
P3. An Umple compiler can accept and generate code that uses nothing but modeling abstractions. The resulting executable can be a module providing an API rather than a complete program. If it has a ‘main’ method and a few extra algorithmic methods it can be a complete program. 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 model (e.g. UML) diagramming tools to generate an Umple program that contains only modeling abstractions, as in P2. Similarly, since Umple features map directly to modeling constructs such as UML class diagrams and state diagrams, one can easily render any Umple program as a UML diagram. This can be done in real-time using an Umple editor such as UmpleOnline that supports Umple textual code, as well as modeling 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, separation of concerns mechanisms, and other 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.
Versions of this document
- The master source of this document, where it can be edited, is in the Umple Wiki
- This document has also been made available in the Umple User Manual