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.
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.
Wiki: BestUmpleUsePractices
Wiki: ContributionProcessToUmple
Wiki: Home
Wiki: UCOSP
Wiki: _Sidebar