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 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.

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 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 (Protg), 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.

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.