CSC/ECE 517 Fall 2009/wiki2 8 rop: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
mNo edit summary
mNo edit summary
Line 4: Line 4:
== Overview ==
== Overview ==
Refection-oriented programming is a new paradigm which deals with understanding the computation as a task rather than a program. Conceptually, it can be thought as the program setting up a "watchdog" to observe the changes and self-modify accordingly based on the observations. One thing to be mentioned here is that this paradigm goes well with dynamically typed languages such as Ruby, Lisp etc. The core behind this paradigm is the flexibility of treating the instructions as data so that all the policies of data modification can be applied onto them.
Refection-oriented programming is a new paradigm which deals with understanding the computation as a task rather than a program. Conceptually, it can be thought as the program setting up a "watchdog" to observe the changes and self-modify accordingly based on the observations. One thing to be mentioned here is that this paradigm goes well with dynamically typed languages such as Ruby, Lisp etc. The core behind this paradigm is the flexibility of treating the instructions as data so that all the policies of data modification can be applied onto them.
== Paradigm implementation ==
In most of the languages as the code is compiled/assembled the structure of the program is lost. However, the key to implementing this programming paradigm is to preserve the structure so that the program can be analyzed and modified accordingly. To enable this, the program structure is preserved as metadata in the code. This ensures that even though the compiled/assembled code doesn't maintain the organization, in favor of optimization mostly, the code can be made self-modified. There are some languages like Lisp which do not separate compile-time and run-time. In such cases, there is no difference in the code.


== Reflective Paradigm ==
== Reflective Paradigm ==
Reflected-oriented programming is the concept used to write Reflective programs. This allows the program architecture to be decided during the course of execution and is not "hard-wired" to the procedural structure. This paradigm supplements the already-existing object-oriented programming to enhance it with the ''self-modifying-code'' feature. The control flow is something which is decided at runtime; this is important since dynamically altered program can change course of execution of a particular event due to modification. Hence, this paradigm requires that the program contain sequence of decisions be implemented rather than the strictness of decision, based on the run-time data.  
Reflected-oriented programming is the concept used to write Reflective programs. This allows the program architecture to be decided during the course of execution and is not "hard-wired" to the procedural structure. This paradigm supplements the already-existing object-oriented programming to enhance it with the ''self-modifying-code'' feature. The control flow is something which is decided at runtime; this is important since dynamically altered program can change course of execution of a particular event due to modification. Hence, this paradigm requires that the program contain sequence of decisions be implemented rather than the strictness of decision, based on the run-time data.  


On a broad perspective, ing
On a broad perspective, tasks can be classified into:
* ''atomic'' : this category of operations/tasks cannot be interrupted and usually consist of a single step
* ''complex'' : this category of operations/tasks involve multiple steps (or atomic operations) and can be interrupted in the middle of computation
 
The reason why these categories are brought up here is that, atomic operations being single step do not have a specific structure associated with them. However, the complex tasks/blocks lose their structure when a program is compiled in a non-reflective language. It is necessary to preserve its architecture for reflective programs. The block can be thought of as a state-machine which has pre-defined states data will be in or transition to in case of specific events. This whole package is the metadata that is saved for preserving the structure or architecture of the program.
 
== Paradigm implementation ==
In most of the languages as the code is compiled/assembled the structure of the program is lost. However, the key to implementing this programming paradigm is to preserve the structure so that the program can be analyzed and modified accordingly. To enable this, the program structure is preserved as metadata in the code. This ensures that even though the compiled/assembled code doesn't maintain the organization, in favor of optimization mostly, the code can be made self-modified. There are some languages like Lisp which do not separate compile-time and run-time. In such cases, there is no difference in the code.


== Purpose ==
== Purpose ==

Revision as of 20:16, 8 October 2009

Reflection-oriented programming

Traditional programming has always separated data from the instructions. Even though the memory system that stores them doesn't make any distinction between them, the way they are handled is the only differentiator. Data is "processed" while instructions are "executed". Reflection-oriented programming is a technique in which the program is made intelligent enough to modify their behavior.

Overview

Refection-oriented programming is a new paradigm which deals with understanding the computation as a task rather than a program. Conceptually, it can be thought as the program setting up a "watchdog" to observe the changes and self-modify accordingly based on the observations. One thing to be mentioned here is that this paradigm goes well with dynamically typed languages such as Ruby, Lisp etc. The core behind this paradigm is the flexibility of treating the instructions as data so that all the policies of data modification can be applied onto them.

Reflective Paradigm

Reflected-oriented programming is the concept used to write Reflective programs. This allows the program architecture to be decided during the course of execution and is not "hard-wired" to the procedural structure. This paradigm supplements the already-existing object-oriented programming to enhance it with the self-modifying-code feature. The control flow is something which is decided at runtime; this is important since dynamically altered program can change course of execution of a particular event due to modification. Hence, this paradigm requires that the program contain sequence of decisions be implemented rather than the strictness of decision, based on the run-time data.

On a broad perspective, tasks can be classified into:

  • atomic : this category of operations/tasks cannot be interrupted and usually consist of a single step
  • complex : this category of operations/tasks involve multiple steps (or atomic operations) and can be interrupted in the middle of computation

The reason why these categories are brought up here is that, atomic operations being single step do not have a specific structure associated with them. However, the complex tasks/blocks lose their structure when a program is compiled in a non-reflective language. It is necessary to preserve its architecture for reflective programs. The block can be thought of as a state-machine which has pre-defined states data will be in or transition to in case of specific events. This whole package is the metadata that is saved for preserving the structure or architecture of the program.

Paradigm implementation

In most of the languages as the code is compiled/assembled the structure of the program is lost. However, the key to implementing this programming paradigm is to preserve the structure so that the program can be analyzed and modified accordingly. To enable this, the program structure is preserved as metadata in the code. This ensures that even though the compiled/assembled code doesn't maintain the organization, in favor of optimization mostly, the code can be made self-modified. There are some languages like Lisp which do not separate compile-time and run-time. In such cases, there is no difference in the code.

Purpose

Testing Methodologies

Integration Testing and beyond


Functional Testing and beyond

Testing Tools

Summary

References

  1. http://cs.indiana.edu/~jsobel/rop.html