Translation of De-abstraction
The purpose of my research on this problem is to find a way to translate the conceptual model defined by a human language and visual representation into a structured representation that computers can use to generate program code. This involves the use of model-driven programming as a technique to help with 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 translated more directly into program code. Model transformation can be applied to problems related to design models, for example, Unified Modeling Language (UML) diagrams, architectural descriptions, and requirements specifications. A more complete explanation is available at Program-Transformation.org 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 more complete explanation is available at Program-Transformation.org 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 help in the development of software for a large avionics system.
Translation steps
As far as possible, the tools and techniques used must be open standards to facilitate their use, reuse or transformation in other hardware or software systems. The user should not have to type any computer code. Instead, diagrams, natural language, and formulas would be used to define the source model.
A user-defined model could be translated into 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 thus provide the results. Recursion can be used to allow the computer to follow a schematic representation of the problem without having to worry about object names. This is particularly tree for representations of trees. Trees are defined recursively because their structure is recursive, so it is natural to traverse them recursively. This deals 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 when software functions cannot be clearly linked to particular objects or nodes in a hierarchy. These are known as cross-cutting concerns, as they can affect multiple nodes. A schematic representation of cross-cutting concerns can be translated into a computer language representation such as AspectJ for Java. [Kiczales et al, 2001] and AspectXML for XML (Extensible Markup Language) www.oreillynet.com/xml/blog/2005/09/part_3_assets_atom_feeds_and_a.html.
An additional translation of the program to a result model that needs to be created to express the results to a user is likely to be required. This model would be a complete categorized description of all the results of the program. This must be represented using open standard information languages such as XML or languages derived from it. This enables the widest possible reuse of information across different hardware and software systems. The result model could be represented as a diagram or as categorized and linked web pages. The full translation can be as follows
Source Model (Human Friendly Representation) – Source Model (Human Friendly Representation) – Computer Program – Result Model – (Human Friendly Representation)
If the user can define the source model, is largely unaware of how the result model is produced, can understand the result model, and this meets the user’s expectations, the translation is successful.
If the user can define the source model, is largely unaware of how the result model is produced, can understand the result model, and this meets the user’s expectations, the translation is successful.
The figure 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 (Protected), and this definition can be read directly by decision support software (Vanguard Studio) which can display the information and color code it. For a more complex example, a higher-level user interface would be required to allow a user to define the problem, and a translation step to the machine-readable model. The units have been left out as the type of equation used and the values in it are not important to the concept. The software can translate the source model into a program and calculate the results. The output program is then translated back into a defined output model using open standard languages such as XML and Java for human-friendly displays of viewable web pages/diagrams.
Diagram – http://www.cems.uwe.ac.uk/~phale/Images/emc2translate.gif
References
Elrad, T., Filman, RE, Bader, (2001) A. Aspect-Oriented Programming: An Introduction. ACM Communications, 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). Transforming a Model-Based Program 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, WG, (2001) Getting started with AspectJ. ACM Communications, 44, 10, 59-65.