From omg-list-errors@omg.org Mon May 5 12:28:22 2003 From: "Stephen J. Mellor" To: "Kerry Raymond" , , "OMG ADPTF" , "Dirk Epperson" , "William G. Tanner" Subject: RE: MOF, OCL and Semantics [was: RE: a question] Date: Mon, 5 May 2003 09:22:35 -0700 RJLRef: ~/02f522/uml2actionlanguagebenefits_SM.030505 | From: Kerry Raymond [mailto:kerry@dstc.edu.au] wrote: | [snip] Yes, one can translate action semantics into | (say) Java but it's often as much work to write the action semantics as it | is to write the Java, so the users don't see the mileage in doing so. We | just don't seem to have the higher-level programming constructs that make | the users think that behaviour specification (in a language-independent | way) gets them some efficiency in terms of effort, readability. On the contrary, it is significantly less work to write the action semantics than to write the Java. We use the UML as a semantic modeling language in which classes represent sets of instances, and each object exhibits its behavior through a state machine. An action language accesses data, sends signals, and establishes the states. In our market (real-time and embedded systems), we translate set operations into optimized operations on minimal data structures. As a simple example, during translation we scan the models for traversals across an association. If none exists, we neither generate code, nor the (un)necessary data structures. Though simple, it is one fewer thing for the developer to worry about. As time has passed we have added other optimizations, some based on patterns of access (as opposed to static analysis of the models) that are then applicable to all memory-constrained systems. The company Conrad worked for, Kabira, reports a 7 to 10:1 ratio of action language lines to generated C++. This comes about for similar reasons as above, but also because their model compiler generates code for transaction safety and rollback. This code is difficult to write and error prone, but Kabira's model compilers generate this code uniformly, accounting for distribution and all that hard stuff. In short, using an action language and associated model compilers provide for: * a higher level of abstraction in which one specifies (eg, sets, not arrays/pointers/lists/hash tables) * constant, consistent, incremental improvement and optimization via model compilers (eg, multiple association traversals) * uniform generation of complex code (eg transaction rollback) And the developer writes just 1 line of action language to produce 7 to 10 lines of target language.... Why the users don't see the mileage in doing so is utterly beyond me. -- steve