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:

  1. 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.
  2. A lemma is simultaneously a contention for premises below it and a premise for a contention above it.
  3. 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.
  4. A theorem is a statement which has been proven on the basis of previously established statements, such as other theorems, and previously accepted statements, such as axioms

Symbolic analysis and the mathematic dictionary

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

  1. Symbols are axioms to be started. Some of them are grounded, but some are non-ground: fuzzy, vague or mental models without exact information.
  2. 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.
  3. 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.
  4. 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:

Proof of Symbolic Analysis described using 7 automata.

Advertisements

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:

  1. A Taxonomy of Model Transformations (see).
  2. Program-transformation.org

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.

Reverse_engineering_Automata

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:

  1. The type system of the input language (XIn)
  2. The type system of the output language (Xout)
  3. 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.

Direct_translation.

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

Erkki Laitila, PhD (2008) computer engineer (1977)