Translation of Object Models to CodeSource: email@example.com
Problem: Compilers translate human-readable programming language to machine instructions. The OO translation approach tries to take this idea one step further and generate program code from abstract object models. How does it work?
H. S. Lahman explained [titles are mine -YS]:
OverviewThe capsule description is that translation assumes one can describe the the problem solution in terms close to the problem space in an object oriented analysis model (OOA) and then translate that deterministically into an implementation for a particular computing environment. To do that the OOA description has to be rigorous and unambiguous.
Currently there are subsets of UML that provide a rigorous and unambiguous notation. However, one still needs something to describe what goes in methods and actions. This is usually handled with an action language that is hopefully as abstract as the rest of the OOA. [...] Currently Rational and the major translation vendors are jointly proposing a meta model for action languages to OMG as an addition to UML.
Translation makes a key separation. The OOA is an abstract solution that is independent of a particular computing environment (i.e., it is implementation independent). So the OOA is about describing the solution to the problem in problem space terms while the OOD is about building a translation engine that will eat OOAs and produce an optimized implementation in a particular computing environment.
Thus an abstract OOA can be ported without change to any computing environment with complete confidence that the solution will work in that environment. At the same time the translation engine does not care about the solution semantics so it can chew on any OOA and produce an optimized implementation of that solution in its environment.
So the short description is that for a translationist the OOA solves the user's problem while the OOD solves the software developer's problems. Not unexpectedly, once one has a rigorous and unambiguous OOA that can be deterministically converted to code, one starts to get a lot of code translators. In fact, the OOD in the translation world is concerned with building general purpose code generators.
Development ToolsYou need a drawing tool, a medium for action languages (which can be graphical as in ADFDs), and a translation engine that can deal with the other two. Currently most of the tools on the market that support translation are monolithic IDEs that provide everything. Examples are Rose/RT (Rational), Rhapsody (I-Logix), Bridgepoint (Project Technologies), System Architect (Popkin Software), Intelligent-OOA (Kennedy-Carter), and ObjectBench (SES).
These tools tend to be pricey because they involve an enormous development effort. Unfortunately they are also limited because they only support one or, at most, a few platforms for the implementation. The good news is that the marketplace is beginning to recognize the value of specialization combined with modern interoperability.
[...] I see the trend of the future being that the drawing tool, the translation engine, and the architectures will be plug & play and vendors will focus on specializing.
BTW, you can build your own translation engine, but it tends to be a daunting task unless you are willing to accept a lot of manual tweaking. [...] if one manually generates the code from an OOA [...] it takes about 5-10% of the total development time. However, pure manual development opens up the problem of maintaining both code and models.
[...] Obviously any of the RAD client/server IDEs that generate complete applications from data models and VB are special cases of translation.
PerformanceA sore point with me. Until very recently the vendors were mostly concerned with getting the translator to produce correct code for the OOA. As a result the generated code was not optimized very well. We had situations where we got as much as three orders of magnitude improvement doing manual generation. Fortunately that is changing very rapidly.
Every major vendor has come out with optimizing versions over the past couple of years. They still aren't great, but they are at least down to small integer factors now. B-) Unfortunately I don't care for the way some vendors have handled the specification of implementation requirements. In some cases they are specified seamlessly in the OOA, which I fell breaks the separation of solution logic from computing concerns.
IMO, the main benefit of translation is the ability to focus on optimization for the particular computing environment without being concerned about problem space semantics. We get lightning fast compilers today because a decade of highly focused effort was devoted to optimization without having to worry about what problem the code writer is solving. I think the same specialization applies to translation -- the scope is just wider.
The Translation EngineA translation engine has three different parts. One is a common meta model of the OOA constructs -- an OOA-of-OOA, if you will. Another is an "architecture" which consists of a collection of mechanisms that can be used to implement OOA constructs. Typically there will alternative mechanisms for each construct. These mechanisms include library routines for things like event queue managers, linked lists, etc.. Commonly there is heavy use of templates.
The last piece is the actual translation engine that accepts a problem OOA and some requirements related to the implementation (e.g., performance) as input. The architectural mechanisms are mapped to the OOA-of-OOA constructs. The translation engine then maps the particular problem OOA constructs to the OOA-of-OOA constructs to identify alternative mechanisms. It then uses the implementation requirements to select the best one and that is thrown into the implementation code.
There are very widely based approaches among various vendors ranging from essentially straight compiler (Rose/RT) through parametization of a compiler (Rhapsody) to pure template based (Bridgepoint). Typically partial translation engines are implemented as a collection of templates and perl scripts that modify the templates.
DomainsThe translationist approach grew out of R-T/E [real-time embedded systems]. One reason is that state machines tend to the the primary mechanism for expressing behavior (all of the tools I know of use FSMs exclusively). The rules of FSMs make deterministic translation much easier and it was the R-T/E guys who recognized FSMs as survival gear in a complex world long before OT. Another was that R-T/E people have to deal with constantly changing hardware underneath relatively stable problem solutions and they wanted a way to be able to port their solutions.
An R-T/E chauvinist would say that if a method solves R-T/E problems, it will solve any computing problems. There is some truth to this because the synchronous world of many applications is a special case of the asynchronous world of R-T/E.
My position is that a translationist OOA is a very general description. By the fact that it is independent of the implementation it becomes highly general. In addition, it describes the solution abstractly in problem space terms. That is also a very general approach.
At another level, from 40-odd years doing MIS, scientific, and R-T/E in a variety of business and academic environments my conclusion is that there isn't any difference in software. One is just moving bits from one pile to another. Business concerns, languages, hardware, tools, and whatnot change but building software is still just about moving bits. [...]
Martin Fowler, Techniques for OOAD - Translation
Rodney Bell, Code Generation from Object Models
Sally Shlaer and Stephen J. Mellor, The Shlaer-Mellor Method
Sally Shlaer and Stephen J. Mellor, Object Lifecycles
Sally Shlaer and Stephen J. Mellor, Object-Oriented Systems Analysis
Bran Selic, Garth Gullekson and Paul T. Ward, Real-Time Object-Oriented Modeling