Applying Batch Standard to Software Migration Engineering

InTech, Jul 2006 by Benton, Allen D

Part two of a two-part series

Dow began its proof-of-concept project to improve design recovery and accelerate the migration process of its batch control system in 2005. Last month's InTech described the company's problems with reverse engineering, starting with computer-readable configuration files (www.isa.org/link/ApplyBatch). The second leg of the process involved forward engineering to distinguish it from traditional software engineering and covered multiple steps emphasizing document automation and software reuse.

Why bother with multiple steps? Semantics. Each step of the process introduces generalization or abstraction into the system description. Abstraction is what allows us to capture the essence of the current system and carry it over to the target system. We can optimize the process when we abstract software artifacts only to a level where the semantics that describe them apply also to the target system. Semantic distance describes the degree to which an abstraction is different from its implementation.

Static analysis techniques

With full access to a running system, you could accomplish design recovery by observing all behaviors under all possible conditions (dynamic analysis). The reality is most systems are continuously online, and many scenarios have safety implications. Techniques such as static analysis rely on source code and configuration data to answer the questions, "What is the system capable of doing?" and "How does it accomplish it?"

In the same way Google was able to capitalize on realizing Web pages contain valuable structural and linkage information, static analysis has demonstrated source code is equally rich in this type of content. We can leverage it to make reverse engineering projects cost-effective. The proof-of-concept work started with the gathering of industry-proven approaches to understanding a software system from a functional perspective. The existing MOD 5 software migration toolkit supports a good bit of these analyses.

Today's advanced techniques

Configuration disintegration starts with a language-specific parser to break source code into tokens a relational database saves as data elements, data flows, and control flows. Certain data elements of interest (analog outputs, digital outputs, and step transitions) then recombine into clusters using dependency graph techniques, which trace flow relationships between program statements. This step removes language syntax variations so general purpose tools and database structures can undergo further analyses.

Pattern matching compares clusters using distance algorithms to look for, such as repetition of data flows and control flows. A comparison algorithm that exploits knowledge of the software grammar is able to point out differences most accurately. Patterns are useful for recovering design solutions within a process domain, which you only need to describe, re-implement, and test once at the functional level.

Program slicing allows the user to view clusters in the context of the original source code. You can generate an extensible markup language representation of the source code and use extensible stylesheet language transformation to create an HTML-based source code listing. Then insert hyperlinks into the source code to allow the engineer to traverse the tree structure of the cluster.

Dependency evaluation takes a macro view of the system by showing the interdependence of data elements with different sub-systems, such as operator displays, recipes, I/O, and reports. Traditional implementations of this technique include cross-reference reporting.

Metrics evaluation will help you access re-implementation and testing risks or highlight overly complex control strategies once you've assigned clusters to control modules (physical model) and phases (procedural control model). Then you can measure characteristics such as size, complexity, quality, and maintainability, and assign them at the cluster and module level.

View exploration makes at least four views available: physical hierarchy, procedural hierarchy, statement type cluster, and source code. No single view of software is best when attempting to analyze functionality.

Flow visualization differs from exploration in that it uses a graphical representation of data flows (Data Flow diagrams) and control flows (State Transition diagrams) to represent portions of the system.

ABOUT THE AUTHOR

Alien D. Benton is engineering partner at PRIME Integration in Dublin, Ohio (adbenton@prime-integration.com).