Lambda the Ultimate

I have used UML in projects. There were two primary usages:

Informal diagrams in the documents

In that case I did not care much about formal semantics of UML. Sometimes formally-incorrect notation has been used because the tool did not support a correct one.

Some aspects of diagrams are often expressed by color and object position in this usage.

In this approach UML is used as substrate for informal, often diagram-specific DSLs. On other diagrams color and position could mean other things (I usually try to be consistent color usage through document).

The diagram has to be understood by brainware. And human brains do a good job of deriving meaning from diagram if informal legend is provided.

"Executable" DSL substrate

Other usage of UML is as a substrate for project-specific visual domain specific languages that are compiled into artifacts participiating in execution of the program. The advantage of such approach is that there is a visual notation and ready to use model from which the code and configuration files could be generated.

Visual notation could be used in documentation. Generated code and other representations are used in models.

In that case I have tried to follow UML pragmatics and syntax constraints as much as possible when defining semantics of DSL. But if UML fail to provide some facility, we worked around it, sometime even violating UML constraints.

Informality of UML definition helped me in both approaches. It allowed using UML to achieve my purposes without much hassle. I do not view UML as a language with formal semantics. It is a language substrate with some predefined constraints and structure. And it could be used to define languages that have a semantics formally or informally defined. I also think that development of Eclipse (GMF) and Microsoft efforts in visual modeling languages should reduce value of UML as visual DSL substrate.

I also think that efforts to fully formally define semantics of UML are doomed: either they fail to be formal and complete or UML will become less useful as DSL substrate. None requires formal semantics of XML, if UML is viewed as DSL substrate like XML, I cannot require formal semantics from UML too.

A conclusion of this paper seems to be that PL's and even UML don't do of good job of representing the semantics of the target domain. This should come as no surprise since the semantics of a PL is basically it's behavior on the computer. Perhaps I should say "practical semantics" since I don't want to make the mistake of confusing behavior and semantics. This is something that ought to concern us all and for which there is a solution. For a long time now people in business have been using rules because the rules and the associated predicate calculus (and knowledge representation)let them directly express a business semantics. The same principle can be applied to any domain. What we are talking about is logic programming with an emphasis on programming. Thus we can have the behavior we want as well as a clear semantics in the target domain.

Am I the only one who feels this way?

I would really appreciate it if, when you linked a paper, you included the names of the authors somewhere in the story text.