Is UML a programming language?_问答_开发者_运维开发者技术经验分享

Could UML be used to program a computer 开发者_如何学Pythonsystem on its own, without a supporting implementation language, e.g. diagrams straight to machine code (maybe via C or C++ etc), without human coding intervention.

I'm going to go against the general trend and share an experience that shows what UML can do today, and what some future version of UML (or another modeling approach) could be.

First a bit of history.

Way back when, people programmed computers in assembly (not going ALL the way back here). Then along came higher level languages like C and Basic. Programmers that were very good in assembly argued that you can't fully express everything the processor is capable of doing (in an optimized manner) in a higher level language. In fact, they were right. Some things were much less optimal from a memory and performance perspective in higher level languages because you could not fully control the instructions issued to the processor.

The thing is, higher level languages provided a much more abstract form of expression. So, they caught on and after a while, people didn't really care that you could not fully control every aspect of the processor because the developers were so much more productive (Moore's Law also helped).

Similar rounds happened with object oriented languages, and again with managed languages. Each time, a higher level of abstraction became available and eventually won out because it was more efficient to use as a developer. In fact, generally inefficiencies in the higher levels of expression disappear as compilers become better and optimization techniques improve.

Model driven development is a higher level of expression. You cannot fully represent any code you could write in, say, C# or Java. Especially not out of the box. However, it is possible to generate a very substantial portion of an application directly from a UML model.

I led the UML-based code generation effort for several rather large projects. In many cases, we could generate 30% to 60% of the entire source code of the (real life, enterprise-class) applications. And that's just with a small team writing generators for a particular domain. Eventually, an entire industry will be behind tools to generate more and more of real-life application from models.

That is the next step in the natural evolution we have seen in our industry time and time again, ever since the first assembly codes abstracted opcodes (there was probably something before that, but that was before my time).

Short answer: no. Some UML modeling tools can generate Java, C++, and code in other programming languages. However, what it generates are usually interfaces and class relationships. These tools generate stubs for which the implementation still needs to be provided, so human intervention is necessary.

There are some tools to convert UML modeling diagrams to into code - specifically, UML state diagrams. For example, I used a tool called "Rhapsody" (from I-Logix) back in 2000 that would convert a UML diagram to C++. It was cool because the tool could run the state machine directly, and could also run code on a remote machine (in this case, a board running vxworks).

But generally speaking, UML is best used as a modeling tool. Use it to model your system and provide diagrams for your design papers, or whatever. Then use that knowledge to develop your system in an organized manner.

In theory? Yes - you could use a gajillion state machine diagrams and specify everything in painstaking detail, then connect the state machine diagrams to methods in your class diagram and run some horribly complicated tool to generate all of this.

But this isn't something you'd want to do. You won't be getting any more freedom in the way you express yourself, because you have to use the right kind of syntax so that the tool will understand everything you write. Not only that, but you'd be able to write the actual code yourself in far less time than it would take you to make all of those diagrams - and the only thing it gives you is that the code is a carbon copy of the spec (because the spec generates the code). That may be a good thing, but since you have no actual code, that also means that debugging means debugging the diagrams - and that is almost surely going to be near impossible.

UML can model a state machine. ~~Thus, it can represent a Turing machine.~~ A compiler with enough sophistication can read this representation and create a binary (executable) representation of the ~~Turing~~ machine.

So, my answer is yes.

Edit

Since my answer seems to be disagreeable to some... let me clarify that this "compiler with enough sophistication" is completely imaginary and probably far in the future... but it seems from the other answers, there are some programs that can generate some boilerplate code or even generate and run a whole program.

I think that proves that UML (or some subset of it) qualifies as a programming language, but probably not a good one.

Yes, it is possible, just check approaches like ExecutableUML (and a new standard along the same lines is coming) that rely on the use of an action language to express the details of the system behaviour (kind of a psedocode with iterators, conditions, and create,read, update and destroy actions).

A completely different discussion is this is worth. Modeling the system with enough precision and detail to be able to generate 100% of the code does not always pays off. I prefer to stick to my pareto principle (or 80-20 rule) for model-driven development: 20% of the modeling effort suffices to generate 80% of the application code

More detailed explanation here: http://modeling-languages.com/blog/content/pareto-principle-applied-mdd

There is now a fully OMG standardized, Turing-complete, execution semantics for a subset of UML 2.3, known as "Foundational UML" (fUML). Look here for a reference implementation and pointer to the OMG spec. There is also ongoing work on an OMG standard UML action language.

For better or worse, when this work is done, fUML will be a programming language.

-- Ed

Class diagram can be forward engineered into programming language depends on the UML tool you are using. I think you still need to code your own business logic etc.

It is not. Not at all.

It can't make decisions (if's) or run loops. It is less of a programming language than a finite state machine. At least a FSM can make decisions. UML dosen't even have state.

Short answer: As it is right now, you can't generate 100% of the code.

You could probably generate the class structure of your systems via Class Diagram, and probably part of the methods' body via Interaction Diagrams and/or State Charts but I think that's about it.

Some links for WeNeedAnswers since I was so affected by his comment:

Object Management Group's UML Home Page
Model-Driven Architecture
Sparx Enterprise Architect product, which supports MDA
Sparx' "MDA Tool for Model Driven Architecture"
"Enterprise Architect with Model Driven Architecture" white paper

That should be a start.

UML action semantics has support for object allocation/disposal, reading/writing attributes and local variables, invoking an operation, throwing and catching exceptions, navigating a relationship, blocks, loops and conditional behaviour, and a whole lot more.

See:

http://abstratt.com/blog/2008/11/02/what-can-uml-do-for-you/

http://abstratt.com/blog/2008/11/07/executable-models-with-textuml-toolkit-12-m1/

To those saying "no": the question is about UML, not the "UML tools you use", folks. UML is a huge language, and tools implement a subset of it, which often can be quite small.

UML2 is just the data for your code generator.

The code generator generalises code by using data from the model (like C++-templates generalise code by using C++-structures as a model).

Working like that, you are able to produce a complete Create, Replace, Update, Delete (CRUD) and Search Application for any given model.

That code implements hooks, callbacks, inheritance or similar techniques, that allow to extend the functionality by hand-written-code, without touching the generated code (which must be seen as intermediate code).