You are currently browsing the category archive for the ‘Book information’ category.

TAXONOMY FOR SYMBOLIC ANALYSIS

Symbols for software engineering

PC

Program comprehension

RE

Reverse engineering

FE

Forward engineering

Pragmatics: Technology spaces for the methodology

Technoloy spaces

GW

GrammarWare

technology focusing on grammars.

MW

ModelWare

technology focusing on models

SW

SimulationWare

technology focusing on code simulation

KW

KnowledgeWare

technology focusing on knowledge capture

MaW

MaintenanceWare

technology focusing on maintenance

TW

ToolWare

technology focusing on tools

The semiotic triad

S

Symbol

O

Object, either Java object or a semiotic object

L

Logic, language

Main symbols of the methodology

T

Task, maintence task

P

Process, program understanding process

H

Hypothesis

Q

Query, question

A

Analysis

I

Interpretation

M

Model

Functional symbols for GW, MW, SW, and KW

E

Element of the model

Atom

Symbolic source code element, a software atom

Action

Computer action or human action

C

Computation: automatic simulation or manual inference

N

Grammar term

R

Rule, production rule, grammar rule

K

Knowledge (K0 = initial knowledge)

Symbols for grammars and automata, and the notation

B

State transition table of finite automata (usually Q is used)

SE

Side effect, any result generated from simulation

Symbolic

Domain specific language for abstracting Java etc

Clause

The main grammar term of the Symbolic language

TM

Turing machine

TM

Rule, production rule, grammar rule
Advertisements

Goals (20) for the Book

  • G1 To find an atomistic, reductionist representation for source code as a basis for a higher-order model, simulation, and user interaction.(48)
  • G2. The main concepts express the metatheoretical relations of the proposed PC according to Peirce’s semiotic triad.(50)
  • G3. To emphasize the meaning of the symbolic language: both in translating source code into an internal language and further into a metalanguage for user interpretations.(51)
    G4. To establish a convention to define an element for symbolic presentation.(52)
  • G5. To implement GrammarWare using a symbolic formalism.(54)
  • G6. To create a model weaver for ModelWare in order to build a reductionist model for embedding Java semantics to it for simulation purposes.(55)
  • G7. To describe formalism for source code simulation according to the automata theory as well as to create a platform for partial simulation.(56)
  • G8. To create a bridge between the code model and the user language supporting the maintenance approach based on KnowledgeWare.(57)
  • G9. To describe transformation semantics between the technology spaces as automata.(59)
  • G10.To express the main relations of the captured knowledge as nested types as a multi-layer presentation.(59)
  • G11.To realize a knowledge access interface containing the three semiotic layers.(60)
  • G12.To create a sequential computation model for SimulationWare.(63)
  • G13.To illustrate how to implement parallel activities, e.g., threads in order to capture program flows.(64)
  • G14.To plan a hierarchical action model to support solving maintenance tasks in the known cognition layers.(65)
  • G15.To express the user’s questions and hypotheses in a formal way, referring to a singular element or a flow of the model or to a derived tree.(66)
  • G16.To show a demonstration for simulating an example and a theoretical approach as regards the captured PC flow using hypotheses.(69)
  • G17.To validate the process – including all technology spaces – by a small sample program by comparing its output tape with a manually estimated program flow.(70)
  • G18.To create a hybrid construction, combining the benefits of OOP and logic programming.(73)
  • G19.To show how a PC process works leading to low-level actions.(74)
  • G20.To formalize the main features of Pragmatics in Visual Prolog and to demonstrate the corresponding tool, JavaMaster.(75)

Definitions

  • D1. Grammar (79)
  • D2. Grammar production rule (80)
  • D3. Semantic id of a grammar term (80)
  • D4. Symbolic Grammar Tool (82)
  • D5. Grammar definition file (83)
  • D6. Automaton A1, Parser generator (83)
  • D7. Pretty printer – generator (84)
  • D8. Automaton A2, Symbolic code description language (85)
  • D9. Definition for the Symbolic language (85)
  • D10. Symbolic clause (86)
  • D11. Symbolic name (86)
  • D12. Symbolic type (87)
  • D13. Symbol table generator (87)
  • D14. Automaton A3, Direct translation (87)
  • D15. Java to Symbolic – translator (88)
  • D16. Atom (source code atom) (103)
  • D17. Symbolic-to-atomic conversion, A4 (104)
  • D18. Symbolic model weaver (104)
  • D19. Type constructor (of the model weaver) (105)
  • D20. Atomistic model (105)
  • D21. Atomistic descriptor: atom command (106)
  • D22. Link of an atom (106)
  • D23. Atomistic hybrid object, AHO (110)
  • D24. Atomistic machine model (automata) (120)
  • D25. Symbolic output tape (120)
  • D26. Sequence builder (120)
  • D27. Simulator (121)
  • D28. Side effect (121)
  • D29. Partial simulation (122)
  • D30. Interactive simulation (122)
  • D31. Selector (122)
  • D32. Simulating method, run (122)
  • D33. Simulating logic (122)
  • D34. Atomistic semantics for state tables (123)
  • D35. State transition table formalism (123)
  • D36. KnowledgeUnit (160)
  • D37. Dependency graph (161)
  • D38. Explanation (162)
  • D39. Argument (163)
  • D40. ProgramConcept (163)
  • D41. TargetObject (164)
  • D42. ProgramContext (164)
  • D43. Hypothesis (165)
  • D44. Theorem (165)

FIGURES (with pagenumber)

  • FIGURE 1 The program comprehension Pragmatics   17
  • FIGURE 2 A horse shoe illustrates a reverse engineering cycle   25
  • FIGURE 3 Main levels of Pragmatics, the methodology 50
  • FIGURE 4 The main approaches for the program comprehension tool 53
  • FIGURE 5 Program comprehension as automata and transformations 58
  • FIGURE 6 Definition of a computable function by a register machine   61
  • FIGURE 7 Pragmatics and the corresponding theories 77
  • FIGURE 8 Defining the Symbolic language 82
  • FIGURE 9 Direct, semantic translation 93
  • FIGURE 10 Atomistic metaphor for the Java main method  102
  • FIGURE 11 The semantics of the symbolic atom   107
  • FIGURE 12 Presenting structural dependencies of an atom as links  109
  • FIGURE 13 Atomistic hybrid object, AHO, the architecture 110
  • FIGURE 14 Class hierarchy of the symbolic atom 111
  • FIGURE 15 The role of the abstract machine and SimulationWare  125
  • FIGURE 16 The functional principle of the symbolic abstract machine  127
  • FIGURE 17 Challenges for analyzing OO programs 131
  • FIGURE 18 Turing model for an atomistic element 149
  • FIGURE 19 Implementation layers for the symbolic abstract machine 153
  • FIGURE 20 Information levels, produced by the symbolic model 154
  • FIGURE 21 Sample code for illustrating its data and Turing model   159
  • FIGURE 22 Bridging from grammar to model, and knowledge unit 161
  • FIGURE 23 A graphic explanation is a set of causal relations 162
  • FIGURE 24 Skill-level presentation (variable X) 167
  • FIGURE 25 A causal chain of a sequence with its pre- and postconditions 168
  • FIGURE 26 A model for evaluating a sequence as a Hoare triple  170
  • FIGURE 27 An automated explanation based on a flow as natural semantics   173
  • FIGURE 28 Action levels based on adaptation, preference, and fallback  176
  • FIGURE 29 Hypothesis resolution approach  178
  • FIGURE 30 Different functions for an operand to be used in tapes  180
  • FIGURE 31 Specifying constraints in a tape   180
  • FIGURE 32 Sample theorems, forward and backward chaining   182
  • FIGURE 33 Resulting model for KnowledgeWare and MaintenanceWare 192
  • FIGURE 34 Architecture levels of the JavaMaster tool 197
  • FIGURE 35 Data flow of the tool  199
  • FIGURE 36 Symbolic icons, illustrating a symbolic Turing machine   201
  • FIGURE 37 Displaying an atom in the atom toolbar   201
  • FIGURE 38 Entering the test code for the abstract machine  202
  • FIGURE 39 Input tape of the atomistic model derived from EXAMPLE 1   202
  • FIGURE 40 Output tape derived from the abstract machine for EXAMPLE 1 203
  • FIGURE 41 A theorem is a selected sequence of atoms, consisting of rules   204
  • FIGURE 42 Configuring a hypothesis for a loop   206
  • FIGURE 43 Interactive theorem prover for Java programs   207
  • FIGURE 44 Simulation results in the theorem prover dialog 211
  • FIGURE 45 Problem formulation dialog   212
  • FIGURE 46 Selecting the understanding strategy 214
  • FIGURE 47 Display for validating functionality   All functions are shown   214
  • FIGURE 48 Display for validating a control flow (side effects not shown)  215
  • FIGURE 49 Display for validating a data flow   215
  • FIGURE 50 A hypothesis for tracing objects, here DataInputStream   216
  • FIGURE 51 Display for validating object flows, constructors   217
  • FIGURE 52 Display for validating state-oriented functionality 217
  • FIGURE 53 Layout of the tool   220
  • FIGURE 54 Data flow in the methodology  223
  • FIGURE 55 Connections from the technology spaces to computer science 254
  • FIGURE 56 Prolog’s computation model 278
  • FIGURE 57 Each goal (call) tries to get solutions exhaustively  279

TABLES (with pagenumber)

  • TABLE 1 Contents of the chapters 19
  • TABLE 2 Tool approaches for software development archetypes    66
  • TABLE 3 Statistics from the file Java  grm for Java the 3rd edition   83
  • TABLE 4 Conversion table between Java and Symbolic 88
  • TABLE 5 The logic behind the symbolic model weaver  104
  • TABLE 6 Categories of atomic links    106
  • TABLE 7 The run method as a state transition table    123
  • TABLE 8 While command as a state table 144
  • TABLE 9 Atomistic semantics for Symbolic with Java compatibility    152
  • TABLE 10 Simulating Java in Symbolic  153
  • TABLE 11 Server-example (see Appendix 1) as a Turing-tape   160
  • TABLE 12 The information ladder based on the atomistic model 166
  • TABLE 13 Making conclusions based on proof results    185
  • TABLE 14 The size of JavaMaster source code: classes and source lines    198
  • TABLE 15 Grammar-oriented symbols of the model   224
  • TABLE 16 The main symbols of the atomistic model   225
  • TABLE 17 The simulator model 226
  • TABLE 18 Maintenance approach 227
  • TABLE 19 Foundation for KnowledgeWare  228
  • TABLE 20 Results from the KnowledgeWare knowledge presentation    229
  • TABLE 21 Proposed type system to cover reverse engineered elements 231
  • TABLE 22 Accuracy of transformations in the proposed PC environment   247
  • TABLE 23 Reference index to the JavaMaster structures of Chapters 4 to 7   281
  • TABLE 24 Examples from Visual Prolog types  282
  • TABLE 25 A Visual Prolog example interface    283
  • TABLE 26 A Visual Prolog example class  284
  • TABLE 27 A Visual Prolog code file   285
  • TABLE 28 Layout for presenting simulation results 287
  • TABLE 29 The input tape from simulation   288

CONTENTS (with pagenumber)

  • ABSTRACT 1
  • ACKNOWLEDGEMENTS  2
  • FIGURES OF THE BOOK 3
  • TABLES OF THE BOOK 5
  • TAXONOMY FOR SYMBOLIC ANALYSIS 6
  • CONTENTS 7

1 INTRODUCTION 15

  • 1.1 Practical challenges for software maintenance 15
  • 1.2 Purpose of the book 16
  • 1.3 The framework for program comprehension Pragmatics 17
  • 1.4 Short overview of the discoveries 19
  • 1.5 Contents of the book 19

2 BACKGROUND FOR PROGRAM COMPR.  RAGMATICS 21

  • 2.1 Software development life cycle  21
  • 2.1.1 Evolution laws 22
  • 2.1.2 Maintenance means a continuous life cycle 22
  • 2.1.3 Reverse engineering and reengineering 24
  • 2.1.4 Best practices of maintenance and reverse engineering  25
  • 2.2 PC as an independent discipline 26
  • 2.2.1 Single-disciplinary approach  27
  • 2.2.2 Influence of individual programmer differences 29
  • 2.2.3 Object-Oriented Program Comprehension  30
  • 2.3 PC integrated into code analysis  31
  • 2.3.1 Connecting PC and static analysis 32
  • 2.3.2 Connecting PC and dynamic analysis 35
  • 2.4 Dividing PC to principal focus areas  36
  • 2.4.1 Grammar related approach 37
  • 2.4.2 Model related approach 38
  • 2.4.3 Behavior oriented approach (Simulation) 41
  • 2.4.4 Knowledge related approach  42
  • 2.5 About Symbolic processing 43
  • 2.5.1 Symbolic terminology 44
  • 2.6 Summary of the related work 45

3 TOWARDS SYMBOLIC ANALYSIS FOR PROGRAM COMPR. 46

  • 3.1 Selected focus 46
  • 3.1.1 Basic ideas and commitments 47
  • 3.1.2 Ideal goal for the theory 48
  • 3.2 Foundation: Purity of concepts 50
  • 3.2.1 Main concepts defining the symbolic layer 50
  • 3.2.2 The user’s side of the methodology  52
  • 3.3 Simplicity of theories: Technology spaces  53
  • 3.3.1 Commitments to GrammarWare 54
  • 3.3.2 Commitments to ModelWare  54
  • 3.3.3 Commitments to SimulationWare  55
  • 3.3.4 Commitments to KnowledgeWare 56
  • 3.4 Accuracy of PC transformations 57
  • 3.4.1 Universal transformation formalism  58
  • 3.4.2 Indentifying higher order types for lower level elements  59
  • 3.4.3 Knowledge transformation set 59
  • 3.5 SimulationWare: Completeness of logic  60
  • 3.5.1 Definition for a computation model for symbols 61
  • 3.5.2 Towards an ideal analysis 62
  • 3.5.3 The base of computer simulation  63
  • 3.5.4 Simulating parallel features, the starting logic of threads  64
  • 3.6 Relevance of questions: referring to use scenarios 64
  • 3.6.1 MaintenanceWare and mental simulation made by the user  64
  • 3.6.2 Organizational approaches have influence in tools 65
  • 3.6.3 Familiarization scenario 66
  • 3.6.4 Testing scenario 67
  • 3.6.5 Troubleshooting scenario 67
  • 3.6.6 Definition for the focused approach towards source code 68
  • 3.7 Certainty of the results of analyses (answers) 69
  • 3.7.1 Does the method give correct answers? 70
  • 3.7.2 Test evaluation possibilities for the results 70
  • 3.8 Correctness of programs and ToolWare 71
  • 3.8.1 Programming approach for tools 71
  • 3.8.2 Hybrid programming, combining logic and OOP 72
  • 3.8.3 Knowledge analysis of maintenance tasks 73
  • 3.8.4 About the formalization and development tool Visual Prolog 74
  • 3.9 Summary of the approach 75

4 SYMBOLIC GRAMMARWARE 78

  • 4.1 Foundation for GrammarWare 79
  • 4.1.1 Definitions for a symbolic grammar notation 79
  • 4.1.2 Implementing the grammar tool  82
  • 4.1.3 The Symbolic notation 85
  • 4.1.4 Abstraction by symbolic transformation  87
  • 4.1.5 Conclusions about the GrammarWare automata A1 to A3  89
  • 4.2 Improving abstract syntax tree 89
  • 4.2.1 Original AST node and its typical implementation  89
  • 4.2.2 The improved formal definition  90
  • 4.3 Raising the abstraction level 91
  • 4.4 Direct translation 92
  • 4.4.1 The principles and the main goals of translating source code  92
  • 4.4.2 Definitions for a direct translation  93
  • 4.5 Symbolic, the symbolic language 94
  • 4.5.1 The Symbolic language  95
  • 4.5.2 Categories of the Symbolic clause  97
  • 4.5.3 Data model of the Symbolic language 98
  • 4.5.4 Operational model of Symbolic language 99
  • 4.6 Summary of GrammarWare, a bridge to ModelWare 99

5 MODELWARE, THE ATOMISTIC SYMBOLIC MODEL 101

  • 5.1 Symbolic model, its definition and features 101
  • 5.1.1 Atomistic model and its features  102
  • 5.1.2 Symbolic atom 103
  • 5.1.3 Automaton A4, Symbolic-to-model transformation 104
  • 5.1.4 Semantic definition for the symbolic atom 107
  • 5.1.5 Arguments of the atom command  108
  • 5.1.6 Atomistic operations: scanning and searching 109
  • 5.2 Atomistic architecture 110
  • 5.2.1 Hybrid implementation for the atom  110
  • 5.2.2 Features of an executable model 111
  • 5.2.3 Creating the model and other model functions  112
  • 5.2.4 Queries to the model  113
  • 5.2.5 Traversing the model 113
  • 5.2.6 Outputs from the symbolic atomistic model  114
  • 5.2.7 Features of symbolic graphs 115
  • 5.2.8 Analyzing sequences and control flows 115
  • 5.3 How to apply the atomistic model  116
  • 5.3.1 Programming model for the symbolic model 116
  • 5.3.2 Atomistic hybrid object  117
  • 5.3.3 Conclusions about ModelWare (Automaton A4) 117
  • 5.4 Summary of ModelWare  117

6 SIMULATIONWARE, AN ABSTRACT MACHINE FOR SOFTWARE 119

  • 6.1 Foundation for SimulationWare  120
  • 6.1.1 Automaton A5, defining a simulation process 120
  • 6.1.2 Automaton A6, the simulation process 121
  • 6.1.3 Conclusions about SimulationWare for automata A5 and A6  124
  • 6.2 Background for the abstract machine 124
  • 6.2.1 Chomsky hierarchy and the corresponding automata 125
  • 6.2.2 Principles for computations in the atomistic model 126
  • 6.2.3 Symbolic abstract machine (SAM) 127
  • 6.3 Technical preconditions for Java simulation 128
  • 6.3.1 Java execution model 128
  • 6.3.2 Sequential computation model 129
  • 6.3.3 Reachability analysis  129
  • 6.3.4 Problems and limitations of symbolic execution  130
  • 6.3.5 Relations of the abstract machine to hardware and performance 130
  • 6.3.6 Influence of the object-oriented paradigm to simulation 131
  • 6.4 Automata theory as a reference for simulation 133
  • 6.5 Foundation for source code simulation 135
  • 6.5.1 Simulation in computer science 135
  • 6.5.2 Source code simulation 135
  • 6.5.3 Complete simulation of the whole application 136
  • 6.5.4 Partial simulation 136
  • 6.5.5 Run method, the nucleus of the simulation  140
  • 6.5.6 Limitations of the simulation solutions in this book 140
  • 6.6 Simulating static procedural commands  141
  • 6.6.1 Simulating a statement block 142
  • 6.6.2 Constants and their semantics (valClause) 142
  • 6.6.3 Simulating operations (opClause) 142
  • 6.6.4 Simulating variable references (refClause)  143
  • 6.6.5 Simulating assignments (setClause) 143
  • 6.6.6 Simulating conditional clauses (pathClause) 144
  • 6.6.7 Simulating loops (loopClause)  144
  • 6.6.8 Simulating method calls (getClause)  145
  • 6.7 Simulating dynamic object-oriented commands 146
  • 6.7.1 Limitations of the partial simulation of object-oriented code  146
  • 6.7.2 A protocol to handle unknown types and object handles  146
  • 6.7.3 Simulating create commands (creatorClause) 148
  • 6.7.4 A protocol to simulate polymorphism 148
  • 6.8 Atomistic and distributed semantics  148
  • 6.8.1 Turing model for the atomistic element 149
  • 6.8.2 Atomistic semantics for defining Java as a high abstraction  150
  • 6.9 Summary: describing semantics by an abstract machine 151
  • 6.9.1 Simulating Java in Symbolic 153
  • 6.9.2 Results from the symbolic model 154
  • 6.9.3 Unified data model for the simulation results 155

7 KNOWLEDGEWARE 156

  • 7.1 Preliminaries for KnowledgeWare  156
  • 7.1.1 Information ladder for knowledge capture  157
  • 7.1.2 Hierarchical action model for capturing knowledge 158
  • 7.1.3 An example code and its simulation model 158
  • 7.2 Foundation for KnowledgeWare 160
  • 7.2.1 Domain-independent definitions for knowledge 160
  • 7.2.2 Problem centric knowledge definitions  163
  • 7.2.3 Summary illustrating knowledge-related information 165
  • 7.3 Illustrating information model for source code  166
  • 7.3.1 Information model for an atom 166
  • 7.3.2 Information model for a flow 167
  • 7.3.3 Information model for ProgramContext 169
  • 7.4 Interaction model using action levels  171
  • 7.4.1 SkillAction 171
  • 7.4.2 Rule Action 172
  • 7.4.3 Knowledge Action 174
  • 7.4.4 MetaAction 175
  • 7.4.5 Combined Action – model  175
  • 7.5 Method: Configuring hypotheses for familiarization and proofing  176
  • 7.5.1 Hypotheses are bridges from goals to actions 177
  • 7.5.2 Model checking approach for a tape based on resolution trees 177
  • 7.5.3 Building a resolution tree: theorems, operands and constraints 179
  • 7.6 Summary of KnowledgeWare 183

8 MAINTENANCEWARE 184

  • 8.1 Extending the method to the maintenance process 184
  • 8.1.1 Learning method based on gradual proving  184
  • 8.1.2 Top-down approach considering the change request  185
  • 8.1.3 Problem recognition 186
  • 8.1.4 Problem formulation 187
  • 8.1.5 Problem analysis 187
  • 8.1.6 A use case: Using symbolic analysis for capturing knowledge 189
  • 8.2 Summary of KnowledgeWare and MaintenanceWare 191

9 TOOLWARE FOR SYMBOLIC ANALYSIS 193

  • 9.1 Requirements for the tool 193
  • 9.1.1 Selected features for the tool 193
  • 9.2 Selected architecture 195
  • 9.2.1 PCMEF – architecture  195
  • 9.2.2 Summary of the selected architecture 197
  • 9.2.3 Some measures of the tool implementation 198
  • 9.2.4 Data flow through the tool 198
  • 9.3 Low level approach, the technology behind ToolWare  200
  • 9.3.1 Graphic symbols for the symbolic Turing machine 200
  • 9.3.2 Prototyping small code examples 202
  • 9.3.3 Capturing knowledge: KnowledgeWare 204
  • 9.4 Symbolic Turing machine for symbolic analysis  205
  • 9.4.1 Principles of symbolic analysis 205
  • 9.4.2 Starting simulation  205
  • 9.4.3 The method to use hypotheses for program comprehension  206
  • 9.4.4 User interface for proving simulation results 207
  • 9.4.5 Code understanding process  209
  • 9.5 Practical use case  209
  • 9.5.1 Practical example, a Server 210
  • 9.5.2 Problem Recognition 212
  • 9.5.3 Problem formulating  213
  • 9.5.4 Simulating critical paths 213
  • 9.5.5 General rules for detecting problems in the output tape 213
  • 9.6 The concluding remarks related to the PC process 218
  • 9.7 Summary of ToolWare  219

10 RESULTS: PRAGMATICS FOR PROGRAM COMPREHENSION 222

  • 10.1 Conceptual framework for PC Pragmatics  222
  • 10.1.1 Splitting Pragmatics to technology spaces 222
  • 10.2 Technology spaces 224
  • 10.2.1 GrammarWare 224
  • 10.2.2 ModelWare 225
  • 10.2.3 SimulationWare 226
  • 10.2.4 MaintenanceWare 227
  • 10.2.5 KnowledgeWare  228
  • 10.2.6 Program type theory 230
  • 10.2.7 Automation decreases efforts of mental simulation 232
  • 10.3 Summary about the goals of Pragmatics 232
  • 10.4 Summary of Pragmatics 238

11 CONCLUSIONS 239

  • 11.1 Combined computation model to support PC Pragmatics  239
  • 11.1.1 Summarizing the Pragmatics computation model  244
  • 11.2 How can Pragmatics meet the scientific ideals 245
  • 11.2.1 Purity of the created concepts 245
  • 11.2.2 Simplicity of the created theories  245
  • 11.2.3 Accuracy of transformations from code to knowledge 247
  • 11.2.4 Completeness of the logic of the technology spaces 247
  • 11.2.5 Correctness of programs of ToolWare  248
  • 11.2.6 Certainty of answers given to MaintenanceWare  249
  • 11.2.7 Relevancy of questions considering MaintenanceWare 249
  • 11.3 Connections to Computer Science 250
  • 11.3.1 Experiments in building PC formalism 250
  • 11.3.2 Created theories for the technology spaces 250
  • 11.3.3 Created knowledge to be used in future research  251
  • 11.3.4 New discoveries to summarize Pragmatics 251
  • 11.3.5 Interdisciplinarity and multidisciplinarity 252

Rest of the book

  • REFERENCES  255
  • SUMMARY  270
  • APPENDIX 1 : SERVER – EXAMPLE 273
  • APPENDIX 2: TUTORIAL FOR VISUAL PROLOG  278
  • APPENDIX 3 : SIMULATION RESULTS OF THE EXAMPLE 287
  • ANNEX 4: DEFINITION FOR SYMBOLIC LANGUAGE 290

  • Paperback: 300 pages
  • Publisher: VDM Verlag (June 21, 2009)
  • Language: English
  • ISBN-10: 363916833X
  • ISBN-13: 978-3639168334
  • Product Dimensions: 8.5 x 5.9 x 0.9 inches
  • Product Description
    Research on program comprehension is important, because the amount of source code in mission-critical applications is increasing world-wide. As a solution for that challenge, a methodology with four stages is introduced. The first stage, GrammarWare, transforms the program into a symbolic form to function as a construction for the model, as the second stage, ModelWare. For the model the idea of an “atom” is presented to combine the benefits of objects for abstracting, and expressiveness of Prolog for tailoring and formalizing the model. The third stage, SimulationWare, implements a symbolic abstract machine, comparable with traditional Turing machine. With its computation model it enables symbolic analysis, which is comparable with dynamic analysis, but has a rather flexible pragmatics. The last stage, KnowledgeWare, is aimed for collecting knowledge for code inspection, error detection and verification of current operations. The methodology is programmed with Visual Prolog and implemented in a tool, which enables the handling of Java code. The practical goal for the methodology is intelligent support for maintenance tasks.

    About the Author
    Dr Erkki Laitila has a long experience as a computer engineer from many companies like Nokia. Since 1999 he has concentrated in reverse engineering using hybrid programming technology to connect object-oriented paradigm and logic for expressing semantics of formal languages as symbols. Symbolic analysis has much potential to be commercialized, too.

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