Translation of Object Models to Code

Related Sites

Overview

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 Tools

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.

Performance

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 Engine

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.

Domains

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