Tuesday, July 25, 2006

Translation and Aspect-Oriented Programming

The diagram shows a plan for weaving Aspect-Oriented Programming http://aosd.net/ into translation that are provided for end-user-computer communication. Aspect-Oriented Programming can be used where certain tasks or properties do not fall within a natural hierarchy. These are called Cross-Cutting Concerns http://en.wikipedia.org/wiki/Cross-cutting_concern, these Cross-Cutting Concerns could be tasks the program needs to perform such as providing printing or security. This same technique could also be used for attributes that the program is to model for example if the program is to model an aircraft wings, a user with sufficient computer literacy skills can model the representation of the wing as a hierarchical diagram. The user can specify relationships between these items that make it possible to make calculations and decisions. For this model some parameters such as efficiency, weight and cost might not fit well in this hierarchical representation. So these parameters could be weaved into the program as cross-cutting concerns in a similar way to the computing parameters.

Once all parameters are weaved into the program it can be translated from a format most suitable to visualisation and user interaction (e.g. OWL Web Ontology Language) to users into a computer language such as Java for implementation. The program would calculate results, and these could be translated back to the user. The results would be fed back in the language used for user interaction and visualisation. XML (eXtensible Markup Language) can also be used in the translation as either a programming language AspectXML, or a language for representing results. The results could be visualised using stylesheets and interactive software, and where useful translated further into other kinds of representations other than trees e.g. SVG (Scalable Vector Graphics) diagrams and graphs.

The diagram shows a plan for weaving Aspect-Oriented Programming http://aosd.net/ into translation that are provided for end-user-computer communication. Aspect-Oriented Programming can be used where certain tasks or properties do not fall within a natural hierarchy
Figure 1

Highly interactive web pages that act like programs to provide a user interface can be used to provide an interactive user driven programming environment.

Highly interactive web pages that act like programs to provide a user interface can be used to provide an interactive user driven programming environment.

For a practical example figure 2 explains the concept for a simple example of the representation of the equation E=MC2. This relationship can be defined by the user. Here this is achieved using an ontology tool (Protégé), and this definition can be read directly by Decision support software (Vanguard Studio) that can visualise the information and colour code it. For a more complex example a higher level user interface would be required to enable a user to define the problem, and a translation step to the computer readable model. Units have been left out as the type of equation used and values in it are not important to the concept. The software can translate the source model into a program and calculate results. The result program is then translated again into a result model defined using open standard languages such as XML and Java for human friendly visualisations of viewable as web pages/diagrams.

The diagram shows a practical example for weaving Aspect-Oriented Programming http://aosd.net/ into a translation that is provided for end-user-computer communication. Aspect-Oriented Programming can be used where certain tasks or properties do not fall within a natural hierarchy

Figure 2

Examples are available from my home page at http://www.cems.uwe.ac.uk/~phale/.

Friday, July 07, 2006

Translation for De-abstraction

The purpose of my research into this problem is to find a way of translating the conceptual model as defined by a visual and human language representation into a structured representation that can be made use of by computers in order to generate program code. This involves the use of model-driven programming as a technique to assist this.

Model-Driven Programming

Model-Driven Programming involves two transformation techniques Model Transformation and Program Transformation. Model Transformation can be used to translate a model with a representation of the problem that a user would be familiar with, into a model with a representation that can be more directly translated into program code. Model Transformation can be applied to problems involving design models e.g., UML (Unified Modeling Language) diagrams, architectural descriptions, and requirements specifications. A fuller explanation is available at Program-Transformation.org a http://www.program-transformation.org/Transform/ModelTransformation. Program transformation is the act of changing one program into another. The languages in which the program being transformed and the resulting program are written are called the source and target languages, respectively. A fuller explanation is available at Program-Transformation.org http://www.program-transformation.org/Transform/ProgramTransformation.

Model-Driven Programming can be an important technique for dealing with complexity. [Gray et al, 2004] explains how this technique can assist in the development of software for a large avionics system.

Translation Steps

As far as possible the tools and techniques used should be open standard for ease of use, re-use or transformation on other hardware or software systems. The user should not have to type any computer code. Instead diagrams, natural language, and formulae would be used to define the source model.

A model as defined by the user could be translated to a model that is more suitable for a computer to interpret. The computer can interpret this model, and follow any relationships defined in it, make any calculations or decisions, and so provide the results. Recursion can be used to enable the computer to follow a diagrammatic representation of the problem without having to care about the names of objects. This is particularly tree for tree representations. Trees are defined recursively because their structure is recursive so it is natural to traverse them recursively. This deal with hierarchies and relationships, but for requirements outside this scope Aspect Oriented Programming [Elrad et al., 2001] could be used to capture and translate these requirements. Aspect Oriented Programming can be used where software functions can't be neatly attached to particular objects or nodes in a hierarchy. These are known as cross-cutting concerns as they may affect several nodes. A diagrammatic representation of the cross-cutting concerns can then be translated into a computer language representation such as AspectJ for Java [Kiczales et al, 2001] and AspectXML for XML (eXtensible Markup Language) http://www.oreillynet.com/xml/blog/2005/09/part_3_assets_atom_feeds_and_a.html.

A further translation is likely to be necessary from the program to a result model that should be created to express the results to a user. This model would be a categorized full description of all the results from the program. This should be represented using open standard information languages such as XML or languages derived from this. This enables the widest possible re-use of the information on different hardware and software systems. The result model could be represented diagrammatically or as categorized and linked web pages. The full translation may be as below

Source Model (Human Friendly Representation) - Source Model (Computer Friendly Representation) - Computer Program - Result Model - (Human Friendly Representation)

If the user can define the source model, remain largely unaware of how the result model is produced, can understand the Result Model, and this meets the expectations of the user, the translation is successful.

The diagram explains the concept for a simple example of the representation of the equation E=MC2. This relationship can be defined by the user. Here this is achieved using an ontology tool (Protégé http://protege.stanford.edu/) , and this definition can be read directly by Decision support software (Vanguard Studio http://www.vanguardsw.com/) that can visualise the information and colour code it. For a more complex example a higher level user interface would be required to enable a user to define the problem, and a translation step to the computer readable model. Units have been left out as the type of equation used and values in it are not important to the concept. The software can translate the source model into a program and calculate results. The result program is then translated again into a result model defined using open standard languages such as XML and Java for human friendly visualisations of viewable as web pages/diagrams.

Diagram - http://www.cems.uwe.ac.uk/~phale/Images/emc2translate.gif

References

Elrad,T., Filman, R. E., Bader, (2001) A. Aspect-oriented programming: Introduction. Communications of the ACM, 44, 10, 28-32.

Gray, J. Zhang, J. Lin, Y. Roychoudhury, S. Wu, H. Sudarsan, R. Gokhale, A. Neema, S. Shi, F. Bapty, T. (2004). Model-Driven Program Transformation of a Large Avionics Framework - Third International Conference on Generative Programming and Component Engineering GPCE, 361-378 - http://www.cis.uab.edu/gray/Pubs/gpce-2004.pdf.

Kiczales, G., Hilsdale, E. Hugunin, J., Kersten, M., Palm J., Griswold, W. G., (2001) Getting Started with AspectJ. Communications of the ACM, 44, 10, 59-65.