PL architecture views: constrution-time vs. runtime, follow up on earlier thread on "can PL have more than one archite Options

[Stan]

Hi:
I follow up on earlier discussion thread on PL architectures (one or more?), with clarifications of some terms, so I start a new discussion thread. We discussed a bit off-line with Paul and Charles, and I included their comments below.

--------
People may have very different things in mind when talking about “PL architecture”. Paul said that “at SEI, we treat architecture as a set of structures (intentionally plural), some of which exhibit run-time behavior and are composed of run-time elements, and others of which consists of non-run-time
elements and only exhibit development-time properties. We call these views, and I would say they are views of the same architecture.”

We agreed that it would help avoid misunderstandings if we always clarified in the discussion which particular PL architecture view we have in mind. Would be great if someone worked out initial PL terms and community agreed eventually on using them.
----------

In my experience (not theory) it is useful to distinguish between these two PL architecture views:

1. “Runtime PL architecture” view (and runtime architecture of a specific PL member):
It is component/subsystem architecture characterized by interfaces, patterns of system organization (e.g., implied by underlying platform like .NET or J2EE, MVC, etc. ) and any other important enough mechanisms that ensure that a system functions properly at runtime.

Runtime architecture may be expressed at different abstraction levels, from high-level blueprint to concrete architecture of a complete, executable system.

The above runtime architecture is close to the concept of software architecture once introduced by Shaw/Garlan. This is still one of fundamental architectural views in the PL context: while there may be variation across details of runtime architectures of PL members, some basic assumptions about runtime architecture are shared by all members. These assumptions common to all PL members mark the boarder beyond which reuse becomes difficult and not cost-effective. In that sense we can talk about “runtime PL architecture" view.

2. “Construction-time PL architecture” view:
An architecture of building blocks from which we construct (derive) PL members. Some level of automation and economic benefit should be there to qualify an approach as a PL. The nature of a “construction-time PL architecture” and the actual form of reuse that happens during PL member derivation, depends on the technology used. E.g., in our mixed-strategy, building blocks are elements of runtime architecture wrapped and instrumented with XVCL to make them adaptable, reusable across PL members.

In our practice, we always come up with runtime architecture for a "default PL member". This is a prerequisite to designing our "construction-time architecture". Then, we build into the construction-time architecture proper mechanisms (with XVCL) to handle possible variations in runtime architectures for different PL members, in the same way as we treat all other variations characterizing a given PL.
Each PL has one construction-time architecture. If there is an overlap between two different PLs (e.g., some building blocks are similar and big enough to make reuse across PL useful), then construction-time architectures for these two PLs should be able to share common building blocks. Sure, you need a technology that will allow you to do that (e.g., we do this routinely with XVCL).


For me having clear distinction between “runtime” and construction-time” PL architecture views is of critical importance. It is often assumed that runtime architecture must be the same as construction-time architecture. I disagree with that. A consequence of not differentiating them is that we limit ourselves to components as building blocks of PL members, and address variations (i.e., derive PL members) by substituting components or by modifying components, mostly in ad hoc way (that is, without knowing precisely which components a given variation affects and how). In all but some special cases, this imposes serious limitations, leads to explosion of component versions and other problems that make reuse ineffective and PL not very useful.


I feel that many problems, such as the extent of variability in PL, are issues that can only be decided on purely pragmatic, empirical grounds, not in the theory or in general. The answer often dependents on a technology used to support PL. For example, whether or not reuse is still cost-effective in view of given architectural variations (or any other kind of PL variations), depends on the technology used: If we use technology X – it may be that only very small variations in runtime architecture of PL members can be handled in a cost-effective way. But things may look very much different if we use technology Y – we can allow for a wider scope of architectural variations, and still reuse to our satisfaction.

Revisiting to “one-or-may architectures” questions: a PL may have variations in runtime architecture of its members (e.g., some PL members may have extra components, even sub-systems, or some changes to component interfaces, etc.) For me that’s strictly pragmatic, not a theory issue: As long as these variations in runtime architecture are not big enough to make reuse too difficult to be cost-effective, no problem to have them.

Stan