Executable Uml
Executable UmlA subset of the UML extended by an action language. The UML permits tool-vendors to define their own UmlExecutionProfile?. The OMG is currently attempting to standardize action semantics within UML (http://www.umlactionsemantics.org/)
In the meantime checkout ArgoUml for CodeGeneration.
A new product for executable UML: Microsoft Visual CODASYL :-)
I'm surprised there's not more discussion about this concept here. Maybe it's on a different page.
Here's my take on it: JoelSpolsky had a good article on his web site a while back called the LawOfLeakyAbstractions?. His point was that abstractions leak: although they make your life easier most of the time, when you debug, you just have to know what's going on underneath. And since what's underneath is usually another abstraction, you end up having to know a ton of stuff to debug problems. Sometimes what you have to know is irrelevant to the programming problem, like how one poor abstraction translates to another.
Programming languages are a notable exception to this rule. Although language abstractions leak, they seem to leak less. Java, for example. Usually, you debug at the language level. It's pretty rare that you need to think about what kind of garbage collector it uses, for example. (But you do need to know that occasionally! It's still leaky, just not as bad as most abstractions.)
Visual builders of the sort that come with JBuilder and Visual Studio .NET lie on the other side of the spectrum. They leak like crazy. They generate actual Java or C# code that goes in your application. When you debug, you have to debug that code, not the visual builder. I really dislike these tools because they introduce a visual language (the builder) without having proper support for it.
I fear that ExecutableUml will be more like visual builders than programming languages. I expect ExecutableUml to generate code and to require you to understand that code when debugging. Imagine if you coded in C++, but had to use a C debugger for debugging. It would be a disaster.
Until ExecutableUml allows you to work entirely at the ExecutableUml abstraction layer, it will remain an academic experiment.
-- JimLittle
(By the way, I'm assuming that "ExecutableUml" is the idea of allowing UML models to entirely specify the program, and thus allow them to be compiled into executables. Please let me know if I'm thinking of something else. -- JL)
We have been trying a different approach to the same problem that executableuml tries to solve. That is, how can we make a notation that is easy for nonprogrammers to understand, and that also generates excutable code that does not have to be debugged at a lower level than the notation itself?
Our approach is via business rules, written in English, with no limitation on vocabulary. Underneath is an interpretr/compiler that assigns a highly declarative meaning to the rules. So, the order in which the rules are written down makes no difference to their logical meaning. The rules are used to automatically generate and run SQL. To help with debugging at the human level (that is, without 'leaking') step-by-step English explanations are available.
The approach is live, online in a system on our site, www.reengineeringllc.com , and experimental use is free. The author- and user- interface is an ordinary web browser. Comments here, cc to ibl@snet.net, would be much appreciated.
(in a way, the system is Wiki-like. You write your rules into a panel in a web page, just as I'm doing now. Then you flip to another page to run the rules and get results.)
-- Adrian Walker
Don't know the exact concept of ExecutableUml by now, but why only thinking of a compiled language, while many new languages growing up today are interpreted? Think of instantiating a design model as an instance of the UML-Metamodel at runtime (what indeed the UML-Tools like Rational Rose do) and interpreting it directly. Or: Think of a UML Virtual Machine, (a bit like the JVM) taking "compiled" UML (means: XMI) as input. An approach to that can be found at: http://www.riehle.org/computer-science/research/2001/oopsla-2001.pdf.
-- DirkDetering
I would like to see more argument against the very idea. For me, a model is a model. It is at a much higher level of abstraction than the code - implementation details are glossed over to some extent and some things are even left off the model altogether. If some people have their way and UML becomes an implementation technology, you are then, by definition, no longer building models to help you understand and communicate a desired solution but building the solution itself.
From a practitioner's point of view, I highly agree with that statement. An interesting article regarding that opinion has been written by Martin Fowler: http://martinfowler.com/articles/purpose.pdf
But on the other hand, I can't see the distinction between 'model' and 'solution' as clearly as you stated it above. Every abstraction is a kind of 'model' of the underlying layer. Seen from this point, every 'code', which is called 'implementation' today, is an abstraction and therefore a model for the compiled binary code or a possible intermediate assembler. Every Macro-Code from which a typical programming language code is generated is an abstraction too. So to make programming visual is only the consequent next step (inspired by the graphical work in PLC, where your connection scheme is directly executed). The only difference is that programming languages and macro code are later abstractions of former implementation systems, but with UML we are coming from the other direction. We had the Model Language for very abstract drawings first and refine and formalize it now to a programming level to draw nearer to the implementation.
If I like it? No, I don't, as I like to specify in texts, even formalized text (sometimes called 'code' ;-) ). It is much clearer for me to step through sources in an IDE than through models with only a few elements in oversized diagrams. And having IDEs now so strong that we are supported by syntax highlighting, tooltips, pretty printer, wizards or code completion, shortcut macros and much more (even generators using templates) which makes us work very fast, we are drawing now complex diagrams in a canvas which reaches far out of the display, fifty percent of our time rearranging picture elements. So I don't think that an approach like ExecutableUML really makes programming easier for those who have to 'implement' the abstract design ideas coming in from OOA.
-- DirkDetering
A friend of mine is taking a university course that covers ExecutableUml. The lecturer says that it's "not a programming language", and "there's no need to design or code." I don't know whether to laugh or cry, and I don't know if he thinks that it's the pseudocodish syntax or the boxes and arrows that makes it not a language. I suppose there are smarter people working on it, but this has spoilt the idea for me.
It looks like a 4GL like Progress: you can largely work in terms of the business domain and have the runtime map things to a database -- as long as your problem domain corresponds to the one imagined by the tool vendor. There's no real capacity to build your own abstractions the way you can in a genuinely powerful language.
I suspect the graphical representation will appeal to some people, without being much of a real advance.
-- MartinPool
Well this is the same fantasy as machine translation (of a natural, say English, language) with semantic understaning in AI. It's not going to happen.
These two endeavors have the same goal- to automatically translate an arbitrarily complex set of relationships across any possible domain from one representation to another.
There's a long history of such attempts, replete with over-optimistic predictions and timetables that were accompanied by huge funding efforts, which were later shown to be chimerical, resulting in a corresponding withdrawal of money.
Of course this time, it's not going to be DoD money, it's going to be some poor investor's money.
The problem with the whole endeavor is roughly as follows. Words (or other symbols and representations) only seem to be capable of representing the natural world and its relationships because there's a human reading those words and filling in the blanks. Those blanks are human being's implicit understanding of real world, which is massive, pervasive, undocumented, undocumentable (but see Cyc and such-like for efforts ) and thoroughgoing and is, in fact, the *real* source of what something, a statement or anything else, means.
You cannot yet have a machine take human speech (or other symbols ) and understand what the human *meant*. It cannot read ambiguous material on arbitrary topics and, roughly speaking, get it right. It cannot read a paper and know what is meant by the article. I can hear the executable crowd saying "yes, our notation will remove all such ambiguity", to which the reply is "yes you'll have to.... bon voyage and don't forget to write".
If there exists a domain so well defined and microscopic, both, and so antiseptically disconnected from the larger world so there is no leakage from it into the domain and yet curiously popular enough to be well known by alleged "analysts", then it's its own branch of math already. What it isn't is anything business analysts deal with in terms of business process as it intersects with reality.
The probable result from this spectacularly doomed repetition of forgotten history is an ideographic "vocabulary" which is every bit as detailed, and therefore burdensome and error prone (as the executableUMLer's would have it) and needful of human engineering and oversight as current languages are.
These efforts may lead to better interfaces for programmers. In fact, creating more abstract views of programs which then permit drilling down into further detail is exactly where programming tools need to go. So don't get me wrong, there's room for compiler-like activities to move up the food chain, and bully for that and those who accomplish it. I even like it when my tool writes my for-loop for me- it makes me happy every time.
But the notion that a language, even in a very narrow and artificial domain, is going to be defined so that every permissible assemblage of its semantic (not syntactic) blocks will mean one and only one thing and at the same time those permissions won't so restrictive as to make what is sayable trivial, is wrong.
The programs that achieve machine translation today between two natural languages have something of the stupid human trick about them, since they rely on a human at both end for meaning and no understanding whatsoever in between. That is not what executableUML implies. It's not *just* a mapping problem, it's a meaning problem, whether they know that now or find that out later.
When programs can not only translate, but answer questions about what they read, then strong AI, of which executableUML is disguised version (disguised from whom? apparently it's proponents! ) will be here and executableUML will be the least magical of things we can do.
-swv
"Any language from which code can be generated automatically is a programming language." -- SeldenStewart?
ProgrammingInUML is a completely different usage than ConceptualModellingInUML. The two should not be confused! -- DavidFlater
For those interested in some opinions questioning the viability of ExecuteableUml? see my rants.
I'd like to see HelloWorld in ExecutableUml and only after that we might have something to talk about.
See Also: VisualProgrammingLanguage, LabView
EditText of this page
(last edited September 20, 2009)
or FindPage with title or text search