Theory

  1. Recognize abstract/logical components within the solution/code. This suits particularly well in a situation, where there is large codebase that requires unifying and refactoring. Focusing exactly how the thing should be done and what’s the logical process.
  2. Estimate and analyze the one level higher abstraction than what is currently being done. It might be worthwhile for example abstract out the technology specific terminology and focus on the logical structure. Abstracting out the technology makes it trivial to change the underlying technology frame with easily maintainable implementation. Sometimes the change might not require changes at all in other than the code generator.
  3. Code the reference solution as usual (this can be before designing the abstraction as it usually helps to realize the proper abstraction). If there are large differences in different logical solutions, estimate how many different references are needed to cover the entire field. Note! This step is really, really important part. Using traditional object oriented environment to constrain the solution will greatly help to spot the logical issues. Generating procedural code right away will risk missing logical and structural errors.
  4. Recognize the absolute information in the logical model; what is logically required for the implementation.
  5. Parametrize the code replacing the absolute information blocks with parametrized content => making the code generation template that is driven by the information gathered above.
  6. The template will include places for the case-specific custom code. However the code is not all over the place, but in strictly controlled places. The implementation is enforced with interfaces, abstract base classes or simply generating method calls to non-existent methods that demand implementation in partial classes.

Visualization of Extracting Abstraction

Extract Abstraction

Practice

  • Architecture visualization tools can be used to recognize and define the logical “boxes” within the software. However this is by no means necessary and no real documentation has to be produced of this stage.
  • Recognize the structure and create XML Schema for it.
    • Before becoming familiar with XML Schemas a visual editor such as Altova’s XMLSpy or Liquid’s XML Studio are of great help.
    • Annotation and document elements in schema should be used to document the design. They aid in the XML intellisense as well as they can be used to generate the supporting document for the design
  • Implement the supporting structure (the step 3 above) with traditional tools; VS 2010 + ReSharper fort example
  • Generate T4 template with Tangible T4 editor (for the intellisense and T4 Toolbox support)
    • There is no support for exporting the template from existing code; would be nice to have controlled/intelligent search-replace on copy-paste from .cs to .tt
  • T4 Toolbox provides custom tool action to be associated with .xsd schema to autogenerate the .ttinclude with the schema classes
    • This .ttinclude will provide the schema intellisense within the T4 editor
  • Fill up the schema implementing XML with any editor that provides XML intellisense with provided schema.

Visualization of Using Abstracted Block

Use Abstraction

Process Component Model

Process Component Model

Scenario for Industry Deployment

Subscribing to Reference Abstractions

Last edited Dec 16, 2010 at 9:56 PM by kallex, version 3

Comments

No comments yet.