Typical scenarios for applying XVCL

Common reasons for escaping from conventional program design techniques to XVCL is to enhance program changeability, non-redundancy, maintainability or reusability. With XVCL, we can open a “virtual window” to critical program areas that cause problems and require enhanced changeability. We may target at any program area (presentation, business logic, database) or a subsystem that requires extra flexibility. We may target at architecture-level changes (such as configuring components and their interfaces), detailed changes in components’ code, or even changes in program documentation or test cases. XVCL allows us to streamline the whole chain of modifications triggered by different sources of change, propagating change to all the affected software parts. X-frameworks can be built to maintain and reuse all the software artifacts related to different versions and releases of software products, such as code, design specification, documentation, test cases, etc.

Most often, we apply XVCL in a domain critical for business, in which we have already developed programs and identified the need for enhanced change management, maintainability or reusability. Typically, we start with existing programs and a list of objectives, and apply XVCL incrementally to selected program areas, based on business needs and technical considerations.

Here is a typical scenario in which we apply XVCL to support systematic reuse via software product lines:

1. Analyze existing programs (if any) in the application domain of our choice
   
   
2. Domain analysis: Analyze and model common and variant requirements for the programs in the domain – the future product line.
   
   
3. Scope the product line: decide which common and variant requirements are to be implemented within the x-framework. Scoping is driven by business need and technical feasibility.
   
   
4. Describe a runtime structure for programs - components and architecture shared by product line members.
   
   
5. Design a default program in the domain. It is a typical program in the domain, the starting point for building an x-framework - a product line architecture.
   
   
6. Develop an x-framework for the product line incrementally: In the first iteration, we frame the default program to cater for selected variants. In the following iterations, we extend the x-framework developed so far by implementing more functionality into it (that is extending the default program) and/or by addressing some new variants.
   
   
7. Future reuse is facilitated via the above x-framework.
   

A similar scenario is used in software evolution and software re-engineering for maintainability. We can focus on specific areas that create a problem. For example, on similar code structures recurring within a single program or across programs. Such redundancies are often caused by code duplication during maintenance or by not exploiting reuse opportunities during analysis and design. Many redundancies cannot be eliminated from programs without compromising other important design goals. But they can always be eliminated at the level of XVCL structures.

Here is a scenario for re-engineering to eliminate redundancies at the level of XVCL structures:

1. Apply clone detection tools to identify the extent of cloning.
   
   
2. Analyze application domain and program design solutions to identify higher-level recurring patterns. Such patterns result in recurring program structures that may involve a number of collaborating classes. Unification of such structures is very beneficial for maintainability.
   
   
3. Identify groups of program structures (e.g., components, classes or methods) that exhibit much similarity. Typically, there will be much cloning among such structures. Yet other structures may implement similar analysis or design concepts, with variants.
   
   
4. Identify program areas that are heavily maintained and select critical areas for re-engineering.
   
   
5. Re-engineer incrementally. In each iteration, build an XVCL solution, a part of the x-framework, to unify clones or groups of similar program structures.
   
   
6. Future maintenance is done via the non-redundant x-framework.
   

Previous     Next