Source code download link

Binaries with Installation Setup will be uploaded soon..

How to make APF Canvas run :

1. Install Eclipse IDE for Java Developers (soon APF will be independent of Eclipse)
2. From “Help > Install New Software” menu, install ‘Graphical Editing Framework‘
3. Run APF Source code in your Eclipse IDE
4. Search for Code Abstracts from searchbox in right, or browse for Code Abstracts from your machine

APF Assembler

Source code download link

Binaries with Installation Setup will be uploaded soon..

How to run APF Assembler :

1. Save output from APF Canvas on your local hardisk
2. Supply input of Canvas file to Assembler by typing path of Canvas output file in source code of Assmembler.py
3. Run Assembler.py and watch it generate the code in path specified inside it

Credits

(in alphabetical order): Bhupinder Bisht, Mohammad Khalid, Ravinder Singh Sandhu, Tarsem Singh, Tushar Goswami

Existing attempts in Automatic Programming field have been through Code Generators, Domain Specific Languages (DSL), and Language Workbenches.

• Problem with Code Generators :

  You have to use ‘a different’ code generator for every domain. This makes automation very limited. Soon when using a Code Generator, you realize that you must write rest of the code by yourself. So for example if you are auto coding a video game software using some popular game code generator, you easily saved lots of time. But now you wanted this video game to do some serious database handling, but this video game code generator isn’t as powerful as a separate code generator which specializes in code generation for database management. Even if you use a database management code generator, you cannot fuse the code generated by these 2 generators together. Hence the limited automation

• Drawbacks of DSL :

  Like Code Generators, DSLs have similar problem. Two DSLs developed by 2 different organizations may not automatically integrate together. Though DSLs are better than Code Generators as you don’t have to learn a generic programming language (such as C++, or .NET) to make your game. Rather the reserved keywords of DSL are named in such an easy manner that if you know the domain (say ‘game programming concepts’ such as collision detection), you will find the Domain Specific Language familiar – and easy to grasp. But thats still not as simple as APF which lets you type requirements of your software in plain english (with sentences and punctuation) & build your software

• Drawbacks of Language Workbenches :
  Language Workbenches produce Domain Specific Languages. Learning curve is significant if you want to create new DSL. Learning curve is also involved in using a DSL because each DSL has a fresh new naming of reserved keywords. You cannot build software by typing simple to understand English sentences. Also, DSL programming is done typically for larger domains (such as voice synthesis, database management) than for niche domains (such as ‘windows registry manipulation’ or ‘common calculations in dentistry’ or ‘common functions in internet marketing’) because creating a dedicated programming language rich with reserved keywords may not make sense for a domain is small & requires only half a dozen functions. Vacuum of lots of such niche domains results in a limited automation, with reasonable chances that you will need to code rest portion of your code on your own by using generic programming language

How is APF different :

1. Less Learning curve for programmers: learning curve may be less for programmers because a brief page explains them how their code can become auto integrateable.
2. Less Learning curve for power users: no need to learn reserved keywords to program your software. Describe your software in plain English like in a demonstration here and auto code your software
3. Support for niche domains: Because converting even a slightest snippet of code into auto integrateable code is easy, and APF accepts contribution from anyone and everyone in its central repository (with loose moderation but tight ratings), hence APF has more chances to auto code niche functions such as ‘windows registry manipulations, or common dentistry functions, or any other function which are rare in domain specific languages or code generator packages

1. Installer for LetoDMS
2. RSS Feed Aggregator and Twitter poster (source will be uploaded soon)
3. Feature additions of Version 0.2 of APF Canvas (the repository search box in APF Canvas. source will be uploaded soon)

1. Metacode your re-useable code
2. Test your metacode using APF Canvas
3. Make your submission live

Or, if you dont have code you can create a wiki page of it, so that someone else posts code against it.

Any portion of code which is re-used. This can be a small function, or a single line of code, or a bunch of several modules containing lots of code. Any such portion of code qualifies to be a ‘code unit’ and can be submitted in APF if it can be re-used in a larger software.

Read more on ‘How Metacoding works’

1. Critique or agree with approach of metacoding and assembling code units, to form larger software
2. Prepare atleast 10 more walkthroughs where some software is built by assembling smaller code units
3. Efficiency of APF improves as repository of APF increases. Prepare report of ‘How many code units must repository contain to auto code a typical software’

Development phase :

4. Ship first version of Assembler CASE tool, repository server, Metacoding IDE plugins
5. Identify code units which are in most demand, metacode them for submission in APF repository

The Project:
Installation script for LetoDMS
There is this open source ‘Document Management Software’ called LetoDMS. At the time of writing of this article, there is no installation script to install LetoDOMS. So to install LetoDMS on your machine, user has to manually perform several installation steps listed here. A LetoDMS user posted on forum requesting volunteers to develop a simple script which performs the installation steps described in here

Our Ingredients & Tools:
that we would use to auto code this installation script :

1. Various code units which were metacoded and contributed by community. These code units (written by a programmer) when assembled together would build our installation script.
2. Assembler tool which reads metacode of code units, to help power user automatically assemble them together. Rather than a programmer, now using the Assembler tool – a power user can assemble the code units to build our installation script.

Lets first look at our ingredient ‘code units’ described on #1 above. Later on, we will walkthrough the ‘Assembler Tool’ described in #2 above.

Lets enumerate the code units, which our repository must possess in order to auto build the LetoDMS installer script. We can enumerate these code units by analyzing ‘manual installation guide of LetoDMS’. Below on the left, we have copy pasted the installation steps of LetoDMS. On the right, I have written comments against each manual installation step – describing the code unit our ADF repository must have so that a power user is able to pick that code unit from repo, and assemble it with other code units to auto code the installation script :

We have listed 8 code units above – which would be contributed by programmers in APF repository. Let us now walkthrough the Assembler IDE to see how a power user would search above 8 code units from repository, and assemble them together to auto code the installer

Walkthrough of Assembler IDE

The first thing Power User wants in his installer script is to create a web form which prompts user for inputs necessary to perform installation of LetoDMS. He wants his web form to look like the figure below:
Fig1.screenshot of a fully developed web form

This would meet requirement #7 listed in requirements document above. To create this web form, Power User searches in APF code repository for keyword ‘create form’ and following search results are shown :
Figure 2.screenshot of search result page

From this screen, Power User chooses ‘create web form’ code unit. This code unit is drawn on Assembler Canvas – like shown in figure below :
Figure3.Screenshot of assembler ide with ‘create new web form’ code unit placed

Dropping the code unit on canvas prompts power user to supply inputs which were needed for ‘create web form’ code unit to work. These inputs are determined by assembler IDE by parsing the metacode of code unit. Power User can supply these inputs by either connecting output of some other code unit with these inputs, or by typing some input manually.

To create form like in fig1, power user starts typing name of each text field as input against ‘create web form’ code unit placed on canvas. On supplying the text field names, the code unit starts exposing its Outputs like in fig4. These outputs contain value typed in text fields by end user
Figure4. screenshot of outputs exposed by code unit

Power user has now finished prompting end user with input form & collected information of user such as DB Name, DB Username, and DB Password. The power user is now ready to connect to database and execute the SQL statement (as in requirement #4). For this the power user searches for ‘execute sql’ keyword in APF repository, picks a code unit which connects to a database and executes a sql query. When this code unit is dropped on canvas, it appears as below
Figure5. Screenshot of ‘Execute SQL Statement’ code unit dropped on canvas

When placing this new code unit on canvas, power user specifies that he wants to call this code unit on ‘submit button click’ event of ‘create web form’. The list of events appearing under ‘create web form’ code unit were determined by assembler IDE by parsing the metacode of code unit.

Several of the inputs required by ‘execute sql query’ code unit are actually the outputs returned by ‘create web form’ code unit. So power user “connects” the outputs of ‘create web form’ code unit with inputs of ‘execute sql query’ code unit as below :
Figure7. Screenshot of inputs n outputs connected together

This process of :

• searching for code units
• connecting inputs outputs of code units
• assigning execution of a code unit under event of other code unit

is repeated until power user draws the entire installer script on Assembler IDE canvas and meets 8 requirements of project like below :

The notable thing here is that Assembler IDE was tightly following the metacode of code units and :

• alerting power user when he would try to connect incompatible inputs with outputs
• preferring those code units in search results which have past record of ‘getting integrated’ with code units on canvas
• preferring those code units in search results which have inputs/outputs compatible with inputs/outputs of code units on canvas

This process also attains the benefits of Why APF