Talk:Executable UML

procedural vs platform specific

I'm not sure that "platform specific" is the right term. Usually "platform specific" is used to describe source code that is architecture specific (x86, PPC, or MIPS; Linux, Win32, IRIX). This becomes very strange when Java is thrown in the mix, because it is described as a architecture-agnostic platform, platform independent, and cross-platform.

On the other hand, procedural programming is the reality of the microprocessor, and is what high level languages like Executable UML attempt to abstract away. The opposite is declarative programming, and in my opinion Executable UML fits within that bucket. Jayvdb 11:32, 23 April 2006 (UTC)[reply]

Hrm, from what I understand xtUML is intended to free developers from having to write any form of source code, whether that be Java, C++ or C: if the developers decide that they want Windows + Linux + Mac OS X platform support they can choose Java, and if they decide they want performance they can choose C++ or maybe even C. In this case, when I say platform I mean the "Java platform", which to my understanding is still a sort of platform - there are specific libraries, JVM etc which all need to be present to provide the supporting platform for the software application. I may very well be using the wrong terminology though. I'm not sure if procedural programming is the right word here, because Java / C++ etc could all be construed as "freeing programmers from procedural programming", which is very different to what xtUML does - xtUML frees devs from writing source code altogether (whether that be Java, C, C++, whatever). I'm hardly an expert though - maybe there's a reference out there which gives a better turn of phrase?

Maybe we could use "implementation specific" instead of "platform specific"?

Or maybe we could use imperative programming instead of procedural programming - procedural to me implies code based around procedures, eg non OO stuff like C. GeorgeBills 12:26, 23 April 2006 (UTC)[reply]

xtUML will also become a platform when it gathers support and nears 1.0, like Java and XUL before it.

I agree 'procedural' brings undesirable baggage along with it; 'imperative' works for me Jayvdb 12:45, 23 April 2006 (UTC)[reply]

Made the change, it's imperative now. GeorgeBills 15:17, 23 April 2006 (UTC)[reply]

scope of executable UML article

Hello! My understanding of executable UML is that it is morphing into a general term. A proper definition would therefore be: "Executable UML is enriched UML that can be executed by a generating code from UML or by running UML directly in a UML virtual machine." I'd suggest to revise the article in putting this first, and then showing the Mellor/Balcer work as (historic) steps towards this goal. Dirk Riehle 10:07, 27 April 2006 (UTC)[reply]

I agree with this. There are a lot of current proposals about executable UML or even executable MOF. The general idea is often only to invent a programming language (Java, Python, etc.) that will be used to "decorate" models. A model decorated with executable fragments may be considered as a program is a graph visit algorithm is provided. We need several things:

establishing the history of executable models, with reference toearly work including mellor and Riehle
linking this to some kind of theory
listing the various tentative approaches like the Xactium one which is one of the more advanced
discussing possible applications of this. For example decorarted models (or marked models) may be used to generate codee, to refactor, etc.
mentioning the various normalization initiatives (orf course it is easy to decorate a model with Java or Python, but will everybody agree?)
also we need to discuss is this is not simply an idea of inventing a better general purpose programming language?

MDE 21:10, 13 May 2006 (UTC)[reply]

Actually, I think UML will end up being simply another (better? hopefully :-)) programming language. Then, the "executable" in front of UML will become redundant. But given the state of the UML spec this seems a long way from now. Dirk Riehle 08:27, 3 June 2006 (UTC)[reply]

OK, sorry if some people think that what I've added is commercial or promotional (65.83.52.198 has been deleting references for this reason). I did actually use those references when writing this piece, so they are an accurate reflection of the source content for this, and I guess I would prefer to not have them deleted. What precisely is the problem with them?

Also, some of you are obviously concerned that this page only reflects one specific implementation of executable UML, and that's probably something that needs to be addressed - sorry for my mistake, I'm not an expert. Maybe we could have one page here which defines Executable UML in general terms and then links to specific Executable UML implementations? Then everyone could add their own technologies to their own pages, eg: Xactium (which still needs content). Would anyone have a problem with that? GeorgeBills 06:11, 15 June 2006 (UTC)[reply]

It looks like there is a lot of misunderstanding of terminology. Executable UML was used by Mellor and Balcer to indicate a specific software development methodology. When we refer to Executable UML, we are referring to the Mellor and Balcer specified methodology. When we refer to executable UML, we are referring to any method of executing a UML model that isn't Executable UML. Whether you like it or not, this is the state of the terminology. Mellor started using the terminology, Executable and Translatable UML, because of the confusion due to this misunderstanding of the terminology.

On the commercial argument, Executable UML is a methodology that can be supported by any UML CASE tool. I don't see the necessity for listing any UML tools, but I also wouldn't consider it an attempt at advertising to list a sampling of Executable UML tools. I'm not sure what the specific policy is on this. --Lwriemen 03:04, 20 October 2006 (UTC)[reply]

Any input you could give on the page would be great. Would it be a good idea to move the page to "Executable and Translatable UML" instead? GeorgeBills 03:32, 21 October 2006 (UTC)[reply]

Determinism in Executable UML

The statement that Executable UML creates deterministic models is at odds with the following correspondence between Marc Balcer and me:

My Question:

Suppose you have a PIM expressed in Executable UML comprising two objects, A and B.

Suppose A sends a signal X to B, and then (as the next action) executes a synchronous query Q on B which returns true if B has received X, and false if B has not received X.

Which of the following is the case:

1. In any execution, Q will always return true.

2. In any execution, Q will always return false.

3. Whether Q returns true of false is not determined in the PIM. Potentially, either could happen.

I think the answer is 3, but would like to confirm this understanding.

Marc Balcer's Answer:

You are correct.

A sender's sending of a signal, and a recipient's receipt of that signal as an event are separate. Executable UML only requires that when the sender sends a signal that it be immediately posted to the receiving state machine. But just because the recipient receives the event does not mean that the recipient must act on it (do a transition and execute a state procedure) right away.

In fact, different architectures will produce different results--and it is up to the modeler to make sure that the models provide the desired behavior regardless of the architecture. We can see these differences by contrasting a queueless and a queued architecture.

In a queueless architecture, a send-signal action is realized as a direct call to the destination object's state machine. This would produce a result in which the destination object's state procedure is completed before the sending object's state procedure.

But in a queued architecture, a send-signal action merely adds the signal to an event queue and the receiving state machine pulls off the event and executes the state procedure when it is able. If the sending and receiving state machines are executing in concurrent tasks, then the recipient's action may execute first or concurrently; if the sending and receiving state machines are in the same task, then (usually) the sender's state procedure completes, then the receiver receives the event, does its transition, and executes its state procedure.

This type of "nondeterministic" scenario is not a fault of executable UML or any architecture, but a consequence of concurrent programming in general.

Keplevic (talk) 15:13, 4 October 2008 (UTC)[reply]

Removed deterministic from description. --Lwriemen

This page urgently needs peer review

It is rapidly moving toward commercial promotion for one or two methodologists or tool vendors. Xactium 05:42, 2 June 2006 (UTC)[reply]

Feel free to be bold and make improvements yourself if you want to. Just make them non-point of view, reference them, etc. You might also like to fill out the Xactium page - you're username is Xactium and your two edits so far consist of adding links to that page, so you probably know what it needs to say. GeorgeBills 07:12, 2 June 2006 (UTC)[reply]