Examples of when and how to apply XVCL

A usual strategy is to apply XVCL only when conventional programming techniques fail to provide a good enough solution.

• Suppose changes during program maintenance have become time-consuming and error-prone because of:
  
  
  • program complexity due to duplicated and modified code structures recurring in many places in a program. We can build generic XVCL structures to unify such similar program structures, at the design and code levels. As XVCL structures are fully integrated with our code, all the future maintenance is done via compact, non-redundant program representation, expressed as mixture of a conventional program + XVCL. We can take under the XVCL's control critical program sections that create much maintenance problems, gradually extending the scope XVCL's coverage, as needed.
    
    
  • complex and invisible impacts of changes in requirements on code. We can build XVCL structures that explicate chains of modifications required to address various sources of change. We can streamline the whole chain of modifications triggered by different sources of change, propagating change to all the affected program parts (and documentation). We may target at the architecture-level changes (such as configuring components and their interfaces) or detailed changes in components' code.
    
    
• Suppose it has become difficult to maintain multiple versions of the same program released to different customers. With XVCL, we can precisely tell what is common from what is different across program versions. We can switch to reuse-based maintenance of multiple program versions, saving maintenance cost.

Next