You are currently browsing the category archive for the ‘Transformation Framework’ category.

In mathematics and logic a traditional proof is done by starting from one or more axioms. Clauses are used as steps (bridges) into higher-order decisions. Lemmas and corollarys are many times useful in order to mark the route to the final decision, which is usually a proof or a theorem.

Below the most important concepts regarding how to derive logical decisions:

- An
**axiom**(or**postulate**) is a proposition that is not proved or demonstrated but considered to be either self-evident, or subject to necessary decision. Therefore, its truth is taken for granted, and serves as a starting point for deducing and inferring other (theory dependent) truths. - A
**lemma**is simultaneously a contention for premises below it and a premise for a contention above it. - A
**corollary**is a statement which follows readily from a previous statement. In mathematics a corollary typically follows a theorem. The use of the term*corollary*, rather than*proposition*or*theorem*, is intrinsically subjective. Proposition*B*is a corollary of proposition*A*if*B*can readily be deduced from*A*, but the meaning of*readily*varies depending upon the author and context. - A theorem

### Symbolic analysis and the mathematic dictionary

In Symbolic Analysis we use the concepts above in the following way:

- Symbols are axioms to be started. Some of them are grounded, but some are non-ground: fuzzy, vague or mental models without exact information.
- Those symbols that are ground and captured from source code – have a certain semantics. A lemma is that for any symbol having a semantic notation, a symbolic notation can be created, because each grammar term is independent of other grammar terms by default. Therefore, each symbol can be simulated separately.
- The corollary is that each source language symbol is an automaton, which can be programmed in a tool as a state machine having the same principal logic as Turing machine.
- The final decision from the steps 1, 2 and 3 above is that by simulating source code it is possible to mimic original program execution step by step. This makes a foundation for interactive program proof.

### Some links:

- What is the difference between theorem.. and corollary by David Richeson.
- Definitions for axioms etc at Wiki: http://users.dickinson.edu/~richesod/
- Ideal of Science: https://symbolicanalysis.wordpress.com/2009/10/22/ideal-of-science/
- Transformation process for reverse engineering: https://symbolicanalysis.wordpress.com/2009/09/09/reverse-engineering/ (the figure describes the symbolic analysis transformation process as successive automata: A1-A7).

### Architecture Driven Modernization (ADM)

ADM –Standards have been introduced in Architecture-Driven Modernization (ADM) Task Force: Overview, Scenarios & Roadmap (see here, page 7).

### Why ADM?

It is a process of understanding & evolving existing software assets for:

- Software improvement
- Modifications
- Interoperability
- Refactoring
- Restructuring
- Reuse
- Porting
- Migration
- Translation into another language
- Enterprise application integration
- Service-oriented architecture

Modernization starts where existing practices fail to deliver against business objectives

- RFP #1: ADM: Knowledge Discovery Meta-Model (KDM) Package
- RFP #2: ADM: Abstract Syntax Tree Meta-Model (ASTM) Package
- RFP #3: ADM: Analysis Package
- RFP #4: ADM: Metrics Package
- RFP #5: ADM: Visualization Package
- RFP #6: ADM: Refactoring Package
- RFP #7: ADM: Target Mapping & Transformation Package

There are 12 modernization scnerios in ADM (see page 9).

### Differences between the Atomistic Model and ADM

The differences are below:

ADM’s packages |
Implementation in the Atomistic Model |

RFP #1: ADM: Knowledge Discovery Meta-Model (KDM) Package | This information (RFP #1) is in the model (see AHO), the Symbolic notation |

RFP #2: ADM: Abstract Syntax Tree Meta-Model (ASTM) Package | This info has the Symbolic notation, it lies in AHOs |

RFP #3: ADM: Analysis Package | Simulation has been implemented using the run method of AHO |

RFP #4: ADM: Metrics Package | There is currently no correspondence |

RFP #5: ADM: Visualization Package | These are graphs generated from AHOs |

RFP #6: ADM: Refactoring Package | There is currently no correspondence |

RFP #7: ADM: Target Mapping & Transformation Package | There is currently no correspondence, but transformation from Symbolic to the input language and back has been done in an external Transformation Framework |

*The principles are then quite different. An atomistic model is really atomistic, not holistic.*

Some links:

In Wiki: A **model transformation** in Model Driven Engineering takes as input a model conforming to a given metamodel and produces as output another model conforming to a given metamodel.

In Wiki: **Model Transformation Language** in systems and software engineering is a language for model transformation

In Wiki: A **transformation language** is a computer language designed to transform some input text in a certain formal language into a modified output text that meets some specific goal.

Some links:

Reverse engineering is a process to transform software via GrammarWare, typically via ModelWare, to Knowledge in order to answer the questions, typical for MaintenanceWare. This process can be modelled as a chain of automata A1 to A7, where user is the last link of the chain.

FIGURE 3.

There is an explanation for the figure on page 58 in the book.

Translation is a process to transform one formal input language into an output language. Translation engine is a tool or software component to implement the translation. One of the best known translation engines is TXL (Dean, 2002), which is based on rule based translation. It needs three different kinds of information:

- The type system of the input language (XIn)
- The type system of the output language (Xout)
- The transformation rule base (Xin2Xout)

*The drawback of the rule based translation is that it contains three different grammars that should be mastered, because the rule base contains a language of its own.* In practice making translations is demanding by using TXL for each input-output language pair.

Hence, direct translation is a process to carry information from an input language to an output language term by term using semantic predicate conversions.

In it we use the symbolic programming language of the tool, here Visual Prolog, as third language to carry information. The principle is illustrated in FIGURE.

The input term has a format in(A1, Ak) and the output out(B1, Bk). If terms match then the conversion is trivially done by splitting subterms into sub-subterms. If they are not directly compatible the Prolog’s notation is used to make the necessary modifications.

.

Translation is a process to transform one formal input language into an output language. Translation engine is a tool or software component to implement the translation. One of the best known translation engines is TXL (Dean, 2002), which is based on rule based translation. It needs three different kinds of information:

– The type system of the input language (XIn)

– The type system of the output language (Xout)

– The transformation rule base (Xin2Xout)

The drawback of the rule based translation is that it contains three different grammars that should be mastered, because the rule base contains a language of its own. In practice making translations is demanding by using TXL for each input-output language pair. A principle different to that of rule based translation is direct translation, which is presented in Definition 14. In this principle the symbolic programming language of the tool, here Visual Prolog, is used as third language. The principle is illustrated in FIGURE 9.

Some conversions are shown below.

TABLE Conversion table between Java and Symbolic.

Some sample conversions |
Java |
Symbolic |

Class | class | def(classDef(…)) |

Attribute/Field | field | def(attrDef(…)) |

Method | method | def(methodDef(…)) |

Statement | statement | depends on the Statement |

Expression | expression | opClause |

Reference | reference | refClause |

Assignment | statement | setClause |

Method invocation | expression | getClause |

Class creator | creator expression | creatorClause |