How does XVCL work?

How does XVCL work?

 

Change is the heart of software maintenance, reuse and generally – software development. Therefore, by mastering change, we tackle some major challenges in software engineering.

XVCL is a mechanism for change. Change plans in XVCL, both human- and machine-readable, are imposed on conventional programs, written in one of the existing programming languages. In general, we can apply XVCL on top of any language that has textual representation, independently of the language syntax and semantics, and no matter what the language is used for. XVCL structures express the syntax and semantics of CHANGE, not the syntax and semantics of programs. XVCL does not introduce any “higher level abstract specification” language.

The following is a general idea of the XVCL technique. Code written in a programming language is partitioned into XVCL structures called x-frames. An x-frame may correspond to any program unit (or part of it) such as a subsystem, interface, program component, group of classes, class, method, attribute declarations, fragment of method implementation – just anything. X-frames turn conventional program units into generic, adaptable and reusable program building blocks: From small number of x-frames, we can generate many concrete components, classes or methods, differing in functional requirements, design decisions or platforms. We create x-frames by generalizing pieces of working programs, and/or by top-down domain analysis.

Partitioning into x-frames is guided by changeability concerns and is not constrained by the rules of the underlying programming language. We apply XVCL whenever conventional program decompositions do not yield programs changeable enough.

Figure 1. An overview of the XVCL solution

We design x-frames (that is, instrument code for change and package into x-frames) for each source of change. We often refer to x-frames as meta-components, as they facilitate generation of concrete program components. X-frames that result from that process are organized into layers of an x-frame architecture, in XVCL jargon called an x-framework. An x-framework creates a virtual window that makes it easier for developers to maintain or reuse programs (depends on the objective). In the reuse via product line approach, an x-framework implements the concept of a software product line architecture.

Suppose we have developed an Editor, in Java or C++ ( Figure 1). But then we see that there are plenty of redundancies among parts of code that implement menus, toolbars, etc. which complicate maintenance. We can “frame” parts to alleviate problems. By framing code for menus – we create a generic menu x-frame capable of generating any menu that we need. We can do the same for toolbars. So rather than having multiple instances of similar program structures (clones), at the x-framework level, we have a single, unified representation, capable of generating all the instances that we need. By unifying similarities in the x-framework, not only do we simplify maintenance, but also foster reuse: Our x-framework facilitates generation of custom Editors, with extra features (e.g., grammar checker) , or with modified existing features. Generating new menus, toolbars and other recurring structures in the presentation layer do not require any new programming. Business logic for new features, of course, must be implemented and an x-framework extended accordingly. However, many of such enhancements just follow patterns already implemented and directly visible at the level of the x-framework – therefore easy to implement.

X-frames represent both, change plans and base program components (such as editor, toolbar, menu in Figure 1). Each x-frame specifies changes for the lower-lever x-frames, and receives changes from the upper-level x-frames ( Figure 1). Therefore, x-frames are both active and passive. This allows us to specify changes of any required granularity level, and with any scope (the higher the x-frame, the wider scope of control).

The top level x-frame called SPC contains change plan specifications for all the modifications related to a given source of change. In Figure 1, the SPC specifies changes required to produce a Notepad from the generic Editor x-framework. Change plans are described in terms of x-frame composition rules and x-frame adaptations, expressed as XVCL commands. These commands are embedded in the code contained in x-frames.

The XVCL processor interprets an x-framework to produce a custom program specified in the SPC. The XVCL processor tr averses x-frames as indicated by XVCL commands, in the depth-first order, starting with the SPC. The processor reads each visited x-frame in sequential order and emits the code contained in the x-frame “as is”. Whenever the processor encounters an XVCL command, the command is interpreted to generate the required variant of the source code. An x-framework represents a family of programs ready for change. Having interpreted the x-framework for a given SPC, the XVCL processor outputs a program with required changes (e.g., Notepad in Figure 1).

Flexible “composition with adaptation” of x-frames is the key means to achieve, changeability, non-redundancy and, therefore, ease of reuse and maintenance. XVCL offers a number of mechanisms to achieve flexible “composition with adaptation”. The <adapt> command includes a lower-level x-frame into an upper-level x-frame ( Figure 1), with possible adaptations. Meta-variables and meta-expressions provide a basic parameterization mechanism to inject genericity into x-frames. Typically, class or method names, data types, keywords, operators or even short algorithmic fragments are represented as meta-expressions that can be then instantiated by the processor, according to the context. However, XVCL parameters reach far beyond that and, at times, we may see the whole sub-hierarchy of x-frames as an actual parameter.

A <set> command assigns a value to a meta-variable. During processing of x-frames, values of meta-variables propagate from the x-frame where the value of a meta-variable is set, down to lower-level x-frames. While each x-frame usually can set default values for its meta-variables, values assigned to meta-variables in higher-level x-frames take precedence over the locally assigned default values. Thanks to this scoping mechanism, x-frames become generic and adaptable, with potential for reuse in many contexts. Other XVCL commands that help us design generic and adaptable x-frames include <select>, <insert> into <break> and <while>. We use <select> command to direct processing into one of the many pre-defined branches (called options), based on the value of a meta-variable. With <insert> command, we can modify x-frames at designated <break> points in arbitrary ways. A <while> command allows us to iterate over certain sections of a x-frame, with each iteration generating custom output. Using these mechanisms, we can tune solutions for ease of change, reuse and “normalize” for non-redundancy.

XVCL is a low level mechanism – it is an assembly language for change management. The rules are simple and elementary – they emulate the way programmers work with code. Yet, these rules are sufficient to conveniently express any conceivable type of change – from small change at the code statement level to architectural changes involving components, interfaces or subsystems. A developer can see and control every detail of the generation rules and generation process. The situation is transparent – a developer gets exactly what he/she had designed into a program and XVCL structures. There are no hidden rules, no abstractions disconnected from code. The generated output contains only code that a developer means to be produced. All this is meant to be that way and is a critical factor that makes our solution (we believe, any general-purpose solution) practical and effective.

There is a huge advantage to keep the heart of the generation mechanism minimal, simple and efficient. On top of that mechanism, we can build domain-specific solutions that hide low level details, and this should be done to boost productivity in that domain. But the fundamental principle of operation – as the nature of change - remains the same, across programming languages and application domains.