In this second post (read the first one here ), Ed Seidewitz talks about the new executable UML standards: fUML and Alf. As editor of the fUML specification and primary author of the Alf specification (apart from Vice President of Model Driven Architecture Services at Model Driven Solutions ) who better than him to describe these new standards?. Hope you enjoy his post!
An executable UML model is one with a behavioral specification detailed enough that it can effectively be run as a program. This can be extremely valuable in order to test and validate the model, independently of the one or more implementation platforms to which the system being modeled will ultimately be deployed. Or, in some cases, the model itself can actually be run as the production implementation, given an appropriate execution environment.
There have been model execution tools and environments for years, even before UML. However, each tool defined its own semantics for model execution, often including a proprietary action language, and models developed in one tool could not be interchanged with or interoperate with models developed in another tool. A previous post described Stephen Mellors quest of more than a decade to change this through OMG standards for precise UML model execution semantics and a UML action language.
In 2008, this led to the adoption of the Foundational UML (fUML) specification, providing the first precise operational and base semantics for a subset of UML encompassing most object-oriented and activity modeling. The fUML specification still did not provide any new concrete surface syntax, however, tying the precise semantics solely to the existing abstract syntax model of UML. This meant that, in order to fully specify a detailed behavior in a UML model, say the effect behavior of a transition on a state machine or the method of an operation of a class one still had to draw a very detailed, graphical activity diagram.
Now, anyone who has ever tried to create and activity diagram down at this level of detail (I have personally done several!) knows that it is a frustrating, time-consuming and error-prone thing to do. The graphical UML activity notation was just not meant to be used at such a level of detail and, in fact, for most people, trying to do such graphical programming is just not intuitive or effective. This is why almost all existing commercial model execution tools provide some sort of action language for detailed behavioral specification.
The adoption of executable semantics for UML finally made painfully clear to everyone the need for a textual alternative to specifying detailed computations using the graphical activity diagram notation. The Concrete Syntax for a UML Action Language RFP, issued by OMG in 2008, asked for exactly such an alternative. The final submission to this RFP was adopted by OMG in 2010 and is currently in finalization.
The adopted action language is known as the Action Language for fUML, or Alf. Alf is basically a textual notation for UML behaviors that can be attached to a UML model any place that a UML behavior can be. For example, Alf text can be used directly to specify the behaviors of a state on a state machine, the method of an operation or the classifier behavior of an active class. Further, the “extended” Alf notation actually includes some basic structural modeling constructs, so it is also possible to do entire models textually in Alf.
Semantically, Alf maps to the fUML subset. In this regard, one can think of fUML as effectively providing the virtual machine for the execution of the Alf language. However, this grounding in fUML also provides for seamless semantic integration with larger graphical UML models in which Alf text may be embedded. For example, there are medium grained processes that can be effectively specified using graphical activity diagrams with precise fUML execution semantics. One can then use Alf to specify the behavior of specific finer-grained actions within such processes but based on the same underlying fUML semantics. This avoids the semantic dissonance and non-standard conventions required if one where to instead, say, use a programming language like Java or C++ as a detailed action language within the context of an overall UML model.
Let me elaborate a bit on the importance of semantic integration. Suppose we have a UML class model that has an association between a Customer class and an Account class and we want to navigate across the association to the Account side and sum up all the balances of all the accounts of a certain customer. Now, the UML concepts of association and navigation do not exist as such in most programming languages. So, if we were to use, say, Java as an action language, such concepts have to be semantically mapped to constructs that exist within Java. One approach would be to treat the accounts end of the association as a Java collection, in which case the desired behavior could be coded as:
Integer totalBalance = 0;
for (Account account: myCustomer.accounts) {
for (Integer balance: account.balance) {
totalBalance += balance;
}
}
But association ends are not really semantically collection objects in UMLrather, they are multi-valued properties with specified multiplicities. The fact that myCustomer.accounts actually returns an object in the Java is dissonant with the UML semantics, and any code that relies on this mapping needs to be specifically avoided. Further, there is the question, during execution, of what kind of concrete collection should actually be instantiatedA Vector? An ArrayList? A HashSet? And why not map to Java arrays rather than collection objects?
The problem is that the semantic mapping to a programming language requires the introduction of exactly the kinds of implementation decisions that one wants to avoid in model execution. Moreover, suppose one would like to deploy to, say, both Java EE and C#.NET platformswhy use Java as the action language and not C#? In general, one would like to keep the model independent of the implementation platform (a well-known tenet of OMGs Model Driven Architecture approach), specifying precise system behavior in the model without committing to the non-essential details of a specific target platform.
Hence the need for an action language that is at the same semantic level as the rest of the UML model. Several existing executable modeling tools already provide such an action language. Alf is also such a language, but one that is an OMG standard that can be consistently implemented across a number of tools, promoting the same sort of interoperability for textual behavioral specification that the UML standard already does for graphical modeling.
Syntactically, Alf looks at first much like a typical C/C++/Java legacy language. This is the result of a conscious compromise on the part of the submission team. Since, despite the issues mentioned above, it is currently not uncommon practice to use Java or C++ as a UML action language, there was a strong desire to have a subset of Alf that would be familiar to such practitioners, to ease their transition to the new action language. Indeed, the Java code example given above is actually syntactically valid in Alf, too, with no change at all.
However, in addition to semantic integration with UML, Alf also provides some convenient syntactic shorthands. For instance, the balance summation loop can be written in Alf as
totalBalance = 0;
for (balance in myCustomer.accounts.balance) {
totalBalance += balance;
}
First, note that while myCustomer.account.balance may look like a regular Java field access expression, what it really does is navigate from myCustomer, across the association to the opposite accounts end, return all the Account objects at that end, and get the balance of each one. Alf adopts the notational convenience introduced in the already standard Object Constraint Language (OCL) that navigation across an association to a multi-valued end automatically collects all the values at that end, so it is not necessary to have an explicit for loop to do this.
Second, note that it is not necessary to explicitly declare the type of totalBalance or balance. The types of these local names are inferred from the result types of the expressions assigned to them, a convenience familiar to users of any modern scripting language.
Further, beyond simple syntactic conveniences, Alf also includes constructs that leverage the inherently concurrent, flow-oriented nature of the underlying fUML activity semantics. These include very powerful capabilities like filtering and mapping similar to those seen in many of the recently popular functional languages. So, for example, the above loop can be more compactly written:
myCustomer.accounts.balance -> reduce +;
And, in this case, the expression maps to a single UML reduce action, which, on an appropriate platform, could be implemented as a highly concurrent operation, rather than as a sequential loop. Further, suppose that myCustomer was to be selected based on email address from the extent of existing customers. This can be simply written (presumably before the statement above!):
myCustomer = Customer -> select c (c.email == myCustomerEmail);
The select notation here maps to a fUML parallel expansion region that, again, could be implemented as a highly concurrent search or even translated into a database query. And, while the ‘=’ looks like a traditional variable assignment, what it really maps to is a data flow in the underlying fUML activity so local assignments do not actually introduce mutable state, which again allows much greater flexibility in the translation to implementation.
The key, here, is that the Alf action language allows even detailed behavior to be specified at the higher level of abstraction provided by the underlying fUML activity semantics. Such behaviors are specified more at the level of what is to be done, rather than how it is to be done , allowing for greater freedom in implementing the behavior on different implementation platforms, especially the new and innovative concurrent platforms appearing today. Indeed, the real power of executable modeling going forward relies on keeping the entire behavioral specification at such a higher level of abstraction.
But does this just turn executable modeling into programming in UML? Well, as both a practicing software architect and a practicing software developer, I can honestly say I am OK with that. No, wait. What I really want to say is “It’s about time!”
More information on fUML and Alf can be found at the following locations:
- fUML 1.0 Specification: http://www.omg.org/spec/FUML/Current
- Alf 1.0 Specification: http://www.omg.org/spec/ALF/Current
- fUML Open Source (Reference) Implementation: http://fuml.modeldriven.org
- Complete Alf Parser: http://lib.modeldriven.org/MDLibrary/trunk/Applications/Alf-Reference-Implementation/dist/ (Further language implementation is still in progress.)
- Presentations on executable UML and SysML: http://www.slideshare.net/seidewitz
FNR Pearl Chair. Head of the Software Engineering RDI Unit at LIST. Affiliate Professor at University of Luxembourg. More about me.
In the past I’ve READ a fair BIT about MDA, AND AT NO point have I ever READ anything that explained why ANY OF it IS a good idea. I don’t think there is any demand for it, except perhaps in large enterprises where the people paying for the tech are 5 levels above the guys that are forced to use it.
With all due respect, as a developer, why would I want this?
James —
See my presentation at http://www.slideshare.net/seidewitz/programming-in-uml-why-and-how. For a longer tutorial in the context of SysML, see http://www.slideshare.net/seidewitz/executable-uml-and-sysml-workshop.
The system engineering community is an interesting case. They have long been used to executing models for the purposes of simulation and analysis. While there is a good deal of support in the SE community for SysML as a common notation, making it executable is very important, and that requires executability for the underlying parts of UML it is based on.
I actually have system engineering background (from long, long ago…), so this all makes a lot of sense to me. But I also have a software development background (starting even longer ago..but never mind), and it makes sense for me from that point of view, too.
But you still don’t have TO do it if you don’t want to!
— Ed
Hi James,
As a Java developer I am investigating ways TO make the systems that I WORK ON easier TO change AND extend.
I have come TO two conclusions…
1) Model driven software IS the best known way TO increase developer productivity.
For instance, instead OF implementing a UI WITH SOME toolkit, LIKE GWT, it would be much better TO CREATE a model OF the UI that you want AND THEN either a) generate specific code that implements the UI, OR b) plug the model INTO an engine that can ‘run’ the model.
Creating a model OF a system IS much easier than implementing a system IN a specific LANGUAGE because you can avoid getting mired IN ALL the technical details AND instead just specify whats important WITH regard TO the system.
Also, your model IS MORE reusable than programming code.
——————
2) Aspect-oriented technology is the best known way to change and customize software.
Aspects allow for ‘separation of concerns’ and thus helps avoid the ‘combinatorial explosion’ of complexity that happens when trying to change/extend/modify monolithic code.
In fUML, signals provide ‘join-points’ for applying aspects.
———————-
Finally,
I am coming to fUML from ‘the bottom’ and ALF brings UML down to my level :-).
“Creating a model of a system is much easier than implementing a system in a specific language because you can avoid getting mired in all the technical details and instead just specify whats important with regard to the system.”
When talking about *formal* models, that are so correct that they can be executed, I doubt that. It is only on a higher level, what the “technical details” are.
(The essence will then be hidden in so called tagged values).
Or to say: “Creating an object structure in Java-Swing is much easier than implementing a GUI in a specific assembler, because you can avoid getting mired in all the painting algorithms …”
is as true in the same manner.
So this is not about “modeling” vs. “programming”, it is about the abstraction level of the language used for some task.
“Also, your model is more reusable than programming code.”
This sentence, in my eyes, makes absolutely no sense.
A “programming code” in language X can always be seen as a “model” compared to language Y , into which it may even be compiled, or the X-interpreter may be written in.
So each language that has compilers or interpreters for different platforms is more reusable that the underlying platform itself.
Has nothing to do with “model” or “code”.
The absolute biggest mistake in this whole discussion is, that “model” is way too often considered equivalent to “UML”, even avoiding more general the term Graphical Representation.
One can create a “model” in a textual language very well. Is that then a “programming language” because it is not graphical?
Or: Is a fUML Model a “model”, only because it abstracts over a specific implementation?
No, it is indeed a programme, and is conceptually in the same league as any other programme, that can be compiled to or interpreted on different target platforms.
So also declarative “programming languages” are about models. And an executable “UML model” is about programming, and you are indeed bound to the programming language you use: UML. And to its restrictions.
In my experience the graphical UML is really helpful when I am in “conception mode”. I.e. planning a system (analysis model) or trying to understand a system (reverse engineering).
But having to work in a graphical mode to get things done even down to the algorithmic part is much too often in my way and having to interact with the graphical tools and the limitations of mouse/screen/printerpaper a.s.o. again reduces the productivity.
So in the same way I can gain productivity simply by using a better textual programming language. Better in the sense of: more expressive, broad set of compilers/interpreters.
In the end, executable UML is one more programming language, which has its pro’s AND con’s about expressivity and usability as each other.
Yes, its TRUE that the line BETWEEN a programming LANGUAGE AND a modeling LANGUAGE IS blurry. However, TO me there IS an important difference BETWEEN a modeling LANGUAGE AND a programming LANGUAGE. Elements IN a modeling LANGUAGE have a shared, well-defined semantics while elements IN a programing LANGUAGE have ONLY the meaning assigned TO them by the programmer. IN this way models ARE MORE meaningful than programming code.
For instance; an attribute IN UML represents a property OF the owning object while an attribute IN a programming LANGUAGE may be an attribute IN the UML sense, OR it might a state variable, OR it might be SOME kind OF metadata.
The difference IS NOT merely a matter OF abstraction but OF assigning meaning TO elements. A model IS MORE reusable because it can be understood ON a higher LEVEL than mere programming code due TO the shared meaning attached TO the elements OF the LANGUAGE.
To me the difference BETWEEN a modeling LANGUAGE AND a programming LANGUAGE IS similar TO the difference BETWEEN RDF AND XML. XML IS merely a serialization format, XML element NAMES do NOT have a well defined, shared meaning IN the way that RDF elements do. elements denote the author? OR should I used the
So FOR instance, given an XML document that describes books, I may OR may NOT be able TO pick out the elements that denote the author (do the
> Elements in a modeling language have a shared,
> well-defined semantics while elements in a
> programing language have only the meaning
> assigned to them by the programmer
I am not sure this helps characterize the difference between programming languages and modeling languages. I think this is more about whether a language provides the constructs the programmer needs out-of-the-box or the programmer has to somehow extend the language so it can support those needs, by composing existing constructs, specializing them, and/or by assigning a new meaning by convention.
Examples: OOP in C (using structs with fields and function pointers), AOP with Java (using annotations to modify represent aspects), Ruby on Rails (by convention), DSLs in UML (using stereotypes) – see, even a huge modeling language like UML cannot support every concept someone might need to represent.
I guess it is up to us to choose the language that provides the mechanisms that are more important. But we will always need to extend the language to satisfy our own needs.
Just TO clear my stand FIRST: I’m the one who usually argues in favor of modeling.
However, I think executable UML itself is a serious misunderstanding in itself. Once you execute something, it is a programming language. That means, either through libraries, language constructs, or code conventions, you deal with the same problem: get your abstract thoughts to actual implementation.
Therefore, its model is just as complex as in any programming language: it’s NOT the model anymore, but the whole system.
Simply the laws OF complexity regarding TO the Turing machine kick IN…
How could this happen?
I think our communities have two misunderstood boundaries, AND maybe they ARE related TO each other.
The FIRST misunderstood boundary IS OF the POSITION OF plans IN engineering. Never ever ANY single building was built purely based ON its plans I believe. A plan IS a rough understanding ON what we want TO achieve.
The sole existence OF Software Engineering IS based ON the assumption that you should think it over before you try TO make it run; going straight TO coding IS just AS nonsense IN this regard than trying TO run the plans. I think that ON the above discussion, I would take a POSITION which IS opposite TO BOTH parties: you shouldn’t run your models, but you should have a – disciplined – method to think through what you want to do first!
The more advanced a building gets, the less formal are the plans: I remember, when we built our house, structural plans were taken with rigor; but then, the size of the toilett was measured by the mason by sitting on a chair, instead of tools. Interior plans were nearly never taken seriously.
The more we go into details, the less elaborate the plans are, and, I believe, the less elaborate they should be. UML taught me what are the crucial things which won’t change:what TO look FOR AT the FIRST DAY, how TO build something WHEN we don’t have too much information, which will still stand the time. Not considering implementation details when dealing with the details – like, not considering what kind of data structure should we use when we’re dealing WITH a reduction – would be irresponsible IN my point OF VIEW. We should use a model which express this: the model encoded IN the programing LANGUAGE.
The SECOND misunderstood boundary IS: who’s the mason of this building? Who is the mason of the electric dreamcastles we build? For years, we thought it’s the low-LEVEL programmer. This IS simply NOT TRUE!
Every single computer LANGUAGE IS an abstraction ON the electronic runtime, OF sparks AND silences. We don’t give a computer a castle: we give a computer a full blueprint of a castle: hey,computer, when they request you to build such a castle – by clicking program.exe – this is what you should do!
So, every single programming language is therefore a full modeling language on its own right, with a full range of abstractions.
Now I understand that Java has a lot of implementation details in it always, even if it hides some of them. To the contrary, python has less of them, for example.
I don’t LIKE the LEVEL OF abstraction OF Java personally, but I think every single programmer would agree WITH me – even Kent Becks, I’m sure, after reading Implementation Patterns from him – that even in code we should build different abstraction layers.
I don’t think java should be the modeling LANGUAGE WHERE we express rough understanding OF use cases; but ON the other side, I don’t think UML or anything coming from the modeling/ system engineering community should be the language where we discuss the details, let alone try to execute it, horribile dictu, in production, not just in simulations.
As the fight we should have for modeling is not what kind of end-to-end language we should use: the fight is about how to think about unknown territories.
Allow me to give you an idea why Executable UML is such a powerful idea. Its all about the level of abstraction both in terms of analysis and design.
You may have played Halo on the Xbox. Its a game that automatically records your sessions and can be made to play them back as video clips.
The interesting thing is how it records the video and the short answer is that it doesnt. What it does is to record the locations and speed of all the entities in the game. To play back the gaming session it simply recreates the video from this metadata.
Not only does this use far less storage but it also allows the camera angle to be moved around and the zoom changed in real-time during play back.
So to draw out the analogy, programming is like recording the video in .avi format (rigid and inflexible). While Executable UML is like storing a database of the entities (configurable, flexible and future proof to a large degree).
Adam —
I think most of use arguing for Executable UML understand the points you make. So I don’t think there IS ANY misunderstanding here — just a different understanding.
As I see it, every program, whatever language it is expressed in, is also a model — a model of an executable computation, if nothing else. Conversely, I have no problem saying that every executable model is a program. And that Executable UML and the Alf action language are effectively programming languages and can be judged as such.
However, it is not true that all models, or even all UML models, are programs. And no one is saying that all UML models must be executable.
The fact is, though, that most of our mainstream programming languages are built up from the computing paradigm of our implementation hardware. And then these languages are enhanced with a plethora of specific implementation frameworks and platform technologies. Almost none of this is essential to specifying what computation we want done — it is just necessary to say exactly how it is really going to be run.
Executable models are based on the idea that you can eliminate the details of these implementation platform choices, while still fully detailing all essential computation. “Less detailed” does not necessarily mean “less precise”. It all depends on what details you abstract away.
And this lets you get the benefits of having an executable environment for validating what you want your computation to be, before making specific implementation platform decisions. OK, sure, you can consider your executable modeling environment to be an implementation platform — but, hopefully, it is a higher-level one than you had before. (If not, feel free to use the one you had before!)
Finally, to reiterate, just because you do executable UML models doesn’t mean you can’t also do non-executable models before or in conjunction with your executable models. Do use case models for requirements. Do architectural views for documentation. Whatever.
In the beginning, FORTRAN was seen as “automatic programming”, because you got executable code from the kind of program description that was formerly considered “design”, but now programming in a higher level language is just “regular programming”. My guess is that, as executable modeling becomes more common, it will be seen more and more as just “regular” programming, while other forms of non-executable modeling will be seen as “real” modeling. It is through this kind of transition that we (occasionally) truly raise the level at which we do programming.
— Ed
Mostly agreed 🙂
I agree that a model is not about being executable or not; a model is about representing the system from a viewpoint in a way that highlights important details regarding the current viewpoint, while hides the uninteresting ones.
Some modeling technologies of UML are practically perfect; along with the ability to check their completeness as graphs / statemachines, being able to do formal proofing, while at the same time making it understandable for every stakeholder from managers to janitors, I don’t think we could have a better one.
Where I think we have a BIT different VIEW IS AT the CURRENT programming LANGUAGE landscape; C++ has too many details, AS it’s as close to the computing platform as possible. But what about python, ruby, scala, php, javascript? What about java?
Why do you say that our mainstream programming languages are built based on the underlying computing platform? What about LISP? What about the .NET CLR? LISP and its derivatives, like javascript, have nothing to do with the platform underneath. Python doesn’t have that much either.
It’s perfectly illustrated by current javascript compilers: they change implementation on-the-fly. If you use a hashmap class-like, it’s compiled AS a class; however, once you start TO ADD random properties TO it, the compiler exchanges the implementation TO a hashmap AT runtime. You don’t have to care.
Why couldn’t we have formal proofing IN java? Such tools exist FOR 10 years, AND were regularly – I mean: AT every SVN COMMIT – applied TO the sourcecode IN SOME companies I was working FOR, TO ensure security, stability AND other quality measures. ON the other side, OCaml IS built TO be formally proovable, LIKE most OF the ML languages. I’ve seen ocaml2js compilers, which means – considering that the compilation is proved by hand – proovable javascript!
Also, how to change a model? If it is encoded within a programming language, I would open it in a corresponding editor, and edit it, by renaming / restructuring / adding elements to it; but that’s exactly what I’d do with a source code! Tools in modern IDEs for some languages (like, IntelliJ for java) ensure project-wide stability with program metamodels, updated at every keystroke.
If I want quick turnaround time, I choose python, as all it takes to update the model is just to save some files. Automatic tool support is coming up, java has better metamodel capabilities “offline” (so, source-code analysis) but with run-time metamodeling, the reflection systems in dynamic languages, like what python has are much better.
Sometimes I have models encoded in data fileformats (read in at runtime instead of compiled), I prefer yaml-based ones personally; I even generate them sometimes from UML diagrams, and I have the ability to display them in UML as well, as the transition is bi-directional, as long as we keep the rules.
However, I prefer to use programming languages and technologies who are able to encode such models in easily-readeable sourcecode. The reason is simple: such languages have evolved in a way to be able to explicitly express our thoughts, and if I’m able TO WRITE a sourcecode file which keeps ALL the explicitness OF a code, while also readeable FOR non-technical people, THEN I think I won.
So, IN executable UML, my problem IS that we loose the flexibility OF UML that it IS NOT meant TO be executed; what remains IS nothing MORE AND nothing less, it’s exactly a programming language, as it is to detail everything to a level where it becomes executable, where we have a model of a system covered from every single perspective needed to be executable, wether by the modeler, the execution environment, or the modeling framework, it doesn’t matter.
And I feel that this problem IS already being solved IN a community which IS doing exactly this FOR the LAST 120 years, since ADA Lovelace: programming LANGUAGE designers.
And I don’t want to leave out all those intermediate steps which aren’t executable: that way we loose the sole thing FOR which UML was originally created FOR IN my perspective: TO be able TO think things through without considering execution.
> where we have a model of a system covered from
> every single perspective needed to be executable,
> wether by the modeler, the execution environment,
> or the modeling framework, it doesn’t matter.
Doesn’t it matter? Isn’t freeing the modeler/programmer FROM HAVING TO specify every single detail the whole point OF raising the LEVEL OF abstraction (C vs. Assembly, memory manag. IN Java vs. C, DATA retrieval IN SQL versus a b-tree library, OO modeling IN UML vs. Java|C#|…, etc)?
(assuming by modeler you mean the developer)
Rafael
http://abstratt.com/blog
“So TO draw out the analogy, programming IS LIKE recording the video IN .avi format (rigid AND inflexible). While Executable UML IS LIKE storing a database OF the entities (configurable, flexible AND future proof TO a large degree).”
Ever had a look into JEE 6 ?
Annotation based Java can be very configurable and flexible.
OTOH we work with UML (MDSD, code generation), and we have the impression that the more you put into the models the more they lose the flexibility as either you “fill the gaps” between model and executable system in the UML model or into the generated code (user sections).
But that was only a side note.
What I miss in the current discussion is the differenciation between the scales modeling vs. programming and textual vs. graphical.
As long as these topics are mixed up, arguments are a bit blurred in my mind.
So: As well as a sequence diagram helps me to understand a specific programme flow, I cannot imagine to design an executable system completely in sequence diagrams (just an example). Discuss a specific algorith in email, forums, wikis, books only by drawing images.
OTOH, UML models have an inner representation, that should be possibly instanciatable out of textual representations (btw: what’s the current status of HUTN?), so gaining the advantages of the current IDE power.
Let’s assume a UML model created and edited in text form: What’s now the topic of “executable” UML vs. programming language?
Det,
Note that for executable UML, notations are usually textual, not graphical (see Alf, TextUML). The discussion here is not about graphical vs. textual.
Also, with executable UML, there are no gaps in the generated code (or code snippets inserted into the model). The models are executable, after all.
Cheers,
Rafael
http://abstratt.com/blog
Hi
I had a thought ON models AND executability that I wanted TO share.
It seems that there IS general agreement that a (software) program IS a model, since it hides LOWER-LEVEL details that can be ignored FOR the purposes OF understanding – every LEVEL OF reality seems TO be a model OF a LOWER LEVEL, AND cosmologists AND physicists search FOR the fundamental LEVEL – the point WHERE quarks AND electromagnetic forces become the modeling constructs. A program IS also executable ON a machine that runs ON electricity – it IS fed IN, it processes AND it produces results.
A graphic model, NOT a software model, FOR e.g. a UML class diagram, IS also executable IN the sense that it IS fed INTO the brain (which, just LIKE machines, also “runs/generates” electricity, it processes AND produces results.
So, BOTH types OF models, i.e. a software program AND a (UML) model ARE executable constructs that run ON electrically-based machines (one biological AND the other silicon).
The synergies BETWEEN these two model types IS interesting – NOT sure whether this comment adds TO OR detracts FROM the interesting debate happening here…
Regards
On Twitter, Jordi said my previous post was cool so Im taking the analogy further to almost breaking point.
In Halo 1 I said that programming is like recording the game video in .avi format.
Of course, you can edit the .avi file (read edit the program). For example, cut and paste the scenes together in a different order, use various types of fades and change the contrast, brightness and colours. Even so, how the characters, buildings and landscape look will remain the same and the video will always be set an alien Halo future.
Ah, but you say with modern digital processing you make the players look like cavemen. I would say that this would be a manual process and therefore time consuming and expensive and still only good for the one video.
What if we use Executable UML and its metamodels? From our video database we can generate a whole new look for the players and environment (read a different programming language) and set the video in a different era say World War II where the weapons function in a different way (read different architectural mechanisms). If the fashion changes from Modern Warfare to costume drama we can regenerate after creating a suitable set of rules (read Software Architecture).
Once thats in place we can take any Halo game video which of course will have a different story and script (read different user Application) and produce a war film or costume drama from it.
Executable UML: Its not just about auto generating in different languages.
Det —
Take a look at the original post these comments are on to see some examples of the textual Alf action language for UML. Alf also provides notations for structural modeling. And, as Rafael mentioned, TextUML does, too.
I don’t think this changes the discussion ON executable UML, other than TO the extentit makes TRUE executable UML possible AT ALL!
— Ed
Yes, its TRUE that the line BETWEEN a programming LANGUAGE AND a modeling LANGUAGE IS blurry. However, TO me there IS an important difference BETWEEN a modeling LANGUAGE AND a programming LANGUAGE. Elements IN a modeling LANGUAGE have a shared, well-defined semantics while elements IN a programing LANGUAGE have ONLY the meaning assigned TO them by the programmer. IN this way models ARE MORE meaningful than programming code.
Is see quite the opposite: elements IN a programming LANGUAGE have a shared-well defined meaning IN order TO be executable, IN order TO be able TO use libraries, IN order TO be developed by international communities, IN order TO be able TO WRITE plugins, etc… Have we ever seen a UML model developed by thousands OF people wordldwide?
I believe ANY executable modeling system IS equal TO a programming LANGUAGE. That’s the definition of a programming language!
I’m waiting TO analysises what shows that Alf OR TextUML ARE Turing-complete OR NOT, but I don’t believe you could create a general executable language, which is able to solve a majority of current software engineering, without being Turing-complete.
In order to UML to be taken seriously, in order to bring back formalized planning at all to the everyday practice of software engineering, I believe the modeling community should concentrate on formalizing and emphasiyzing the non-executable part: where that well-defined meaning is taken seriously to achieve robustness, proovability, not to execute it – we had great tools for executed modeling before UML.
I’m NOT saying AT ALL that extensive modeling knowledge didn’t help me to become a better programmer. it did; approaching every single problem first from a modeling standpoint, trying to understand what is what, what are the best viewpoints to approach them from; it did help me, it made me differentiated within programmers.
But constraining yourself to the execution environment, because anything goes, if you want to execute it, you will be constrained by it, for me, it is the giving up of the idea of platform independent modeling itself.
For me, trying to drive UML into an executable direction is a step back, rather than a step forward: it’s the same think IN terms OF execution FROM DAY zero OF a project what we had without UML.
I don’t think a model has to be executed at all, even in brains.
For so-called behavioral models, yes, you have to be able to see that information doesn’t GET lost, that it IS always there, it IS always just the information you need, NOT terrabytes OF memory occupied FOR a design error.
Therefore I use a version OF activity diagrams WHERE ALL the inputs AND outputs OF a given ACTION ARE placed ON top AND AT the bottom OF the ACTION itself; I greatly murmored WHEN certain modifications IN UML 2 beta regarding TO control AND DATA flows got voted down.
But structural models, LIKE taxonomies aren’t to be executed: they are to understand a system from a standpoint.
Even some behavioral models, like certain kinds of Petri nets aren’t TO be executed; they show a flow indirectly related TO the execution OF a given software.
Execution IS NOT, was never, AND should NOT be the ONLY viewpoint WHERE we model FROM. This IS the power OF UML.
Maybe my point still wasn’t clear.
Let me go back TO the basis OF scientific modeling: a model IS a VIEW OF a system FROM a given standpoint, hiding details uninteresting FROM that standpoint AND emphasizing others.
A difference BETWEEN a system AND a model IS, that the model might be complete OR incomplete FROM a given standpoint. A taxonomy, listing the kingdom Animalia, IS incomplete if it doesn’t contain birds, but it is not incomplete when it doesn’t detail what color a bird’s feather could have; it’s an uninteresting detail.
A system however, IS always complete FROM every single viewpoint, because, it IS the system. Even if I don’t model the taxonomy of a system, it may have one, even if it’s a bad one. It has SOME memory management behaviour, even if I never modeled it (a problem that was common WITH early CASE-tools: SOME OF the results were too slow TO use).
An executable system, used IN production therefore, FOR me, IS NOT a model: it covers every perspective OF a system, since it wouldn’t run otherwise! “we don’t have classes since the class model IS missing” – hmm? 🙂 This won’t happen of course.
Of course, we are humans, with carbon-based brains instead of silicon, so we will have only models of this executed system. The question is, was, and will be always, what parts of the system to take into consideration, and what parts do we let happen accidentally, or decided by the platform.
What to consider, what to model, what to highlight, what not to care? What should be reflected in the implementation language, what should be in data files, formats, structures, what should be left accidental, implicit?
These are hard questions: we didn’t get new, fresh answers since the mid-90s, while some of our problems are quite new since then.
How to model web-based interactions correctly? Could we give model-based predictions of large-scale softwares, like behaviour of successful social networks? What to look for when trying to increase performance? How to model parallel execution safely?
When I last heard about performance modeling, it still dealt with sector-positions on harddrives. I’m nearly sure this is not the way they should be designed now, this is not something to be highlighted.
There are so many open questions to answer, which need new and new models, being able to glue them into a universal framework of concepts, for which UML would be the best choice.
Why trying to solve problems which are solved by our programming languages?
> Why trying to solve problems which are solved by our programming languages?
Well, the fact that one thing can be solved with “A” doesn’t mean that we should stop trying TO solve it IN a better way WITH “B”!
I think this applies here. Strictly speaking we can do everything without modeling but I believe that WITH modeling somethings can be solved IN a better way (IN the same way that, strictly speaking, we don´t need ANY programming languages either EXCEPT FOR the Assembly LANGUAGE) but I see the new ones popping up every DAY
That’s FOR sure, but ARE we sure we know how others deal WITH what?
As a poliglot programmer, without too much headache, I’m using javascript, java, python and php in the same project, whatever models a given problem field better – in this context, where is the program more easier to understand – while trying to understand the design considerations behind them.
Java had a lot of common with the design considerations of such executable UML languages: being platform-independent, hide implementation details, while being exact and specific about semantics. Especially this last part makes java programming painful and slow for me, but that’s about personal taste probably.
In CASE it’s not about personal taste, and being overly specific in an execution environment – without dealing with implementation details! – is hard, shall we aim for another platform-independent, but overly specific language?
I like to use DSLs, I like to use data formats describing behaviour, I like to use interactive (modifiable) graphical representations of certain system parts, like orchestration. I prefer to choose programming techniques in existing languages to express a particular problem domain.
I am for to have specific models, have strict designs and loose languages to implement them in, because the ease of not thinking about execution in design, and not thinking about expressing some parts of well-formedness while programming gives me the feeling of maximal freedom, speed on one, and safety and quality on the other end.
Am I alone with this? Am I alone with the need of strict separation between design and implementation? The separation of the tools I’m thinking things through AND the things I express them TO a computer?
Am I alone WITH the need OF specific execution languages based ON a given DOMAIN?
For me, anything ELSE IS the same AS we had: design IN the implementation LANGUAGE, have general languages.
[…] that aims AT this IS the recent fUML standard (released IN February 2011 by OMG) (see also this quick summary by Ed Seidewitz, one OF the main proposers OF the LANGUAGE, AND SOME additional notes FROM the OMG […]
I fully agree with Adam’s whole standpoint. Putting ON the scene executable models, AND IN particular executable UML, IS the worst modeling community move since round-tripping.
Executable UML, which Ed said TO be Turing complete, IS maybe a promising programming LANGUAGE. Modeling may be used FOR various purposes, including system modeling, AND executable models may be a very good answer TO SOME OF these purposes. But the point IS NOT here.
Even if one want TO see them overlapping, modeling AND programming ARE by very nature different activities (my opinion). The “IT world” does love programming, mainly because it sounds material AND pragmatic, but suffers FROM a considerable lack OF back stand ON why doing these programs AND why this way. Modeling brings answers, by helping TO focus ON the problems OR ON the KEY principles rather than ON a detailed solution. AND modeling AS a unified mainstream notation (I do NOT use LANGUAGE here ;D) FOR that : UML.
I think momentum FOR modeling (AND also FOR MDE) IN this decade IS still there, but if we GET the “IT World” confused about modeling vs programming we ARE losing something.
[…] Discussions: MDA/MDA: Don’t roundtrip, MDA/MDD: Model is not code!?, The New Executable UML Standards(see comments) Background: I just read “Executable UML – A foundation for Model-Driven […]
Dear all, I’m interested in combining valid fUML models and MARTE profile. Do you know any (research) work on this two topics?