Elaboration vs Translation

I described in my note comparing "mainstream" software development methods with "alternative" methods, I suggested that mainstream methods develop by elaboration and refinement, while alternative ones develop by translation. The comparison between the two was summarised by Sally Shlaer and Stephen J Mellor, in their paper "Recursive Design of an Application-Independant Architecture", and I cannot descibe the difference any better than by quoting from that paper:

Current View
Although practitioners within our industry hold diverse views, we believe that the following five widely held assumptions constitute the core perspectives on object-oriented methods, patterns, and architectures.

1. Analysis treats only the application—the subject matter of interest to the system’s end user, such as air traffic control, a telephone switch, an automated warehousing application, and the like.
2. The analysis must be couched in terms of the conceptual entities of the design. This assumption appears in much of the work on domain-specific software architectures, as well as in many object-oriented analysis and design methods. Hence a developer employing an object-oriented analysis method is necessarily constrained or biased toward an object-oriented design.
3. Despite the lack of a universally accepted definition for architecture, most people would agree that an architecture provides a view of the entire system. Because this view emphasizes the major elements of the system, many details are necessarily omitted.
4. Patterns are generally thought of as small units, consisting of a few objects with wellworked- out interactions.
5. Programmers expect to select, adapt, and modify patterns according to taste and experience. Patterns are seen as useful but advisory in nature: Use of patterns in general or in particular is not required.

An Alternative View
Our Recursive Design method is founded on a fundamentally different approach to this topic that makes five very different assumptions:
1. An analysis can be performed on any domain, not just the subject matter of interest to the system’s end user.
2. Use of an OOA method does not imply anything about the fundamental design of a system.
3. Because we treat the architecture domain just like any other domain, it can be modeled in complete detail using an object-oriented analysis method.
4. The OOA models of the architecture provide a comprehensive set of large-scale, interlocking patterns.
5. Because all the code other than purchased packages is automatically generated, use of the patterns is absolutely required. Read More...