At first I expressed my personal expectations:
  1. The solution should be an extension of the existing concepts like modular, component based, object-oriented programming and so on.
  2. The structure of the developed application should remind the developer of data flows.
  3. Dependencies between software components should be minimized. No component should know anything about other parts.
  4. No component should know anything about the flow in which it is used.
  5. The assembling of the application from these components should be done by a helping module (That’s the reason why it’s called AppBuilder).
  6. The usage of the tool should be as easy as possible. A few code lines must be enough.
  7. The tool should be applicable in (almost) all scenarios without constraints.
  8. The tool should be used only for assembling and preparing. There’s no runtime environment like NPantaRhei.
  9. The parts of the software may be spreaded into multiple libraries. The tool has to handle this issue.
  10. The startup of the build application has to be fast as possible. Less than one second delay has to be enough.
  11. The description of the flow has to be very simply structured. Only a few key words have to be enough.
  12. It should be possible to edit the flow definition with a normal text editor.
  13. The layout of the flow definition should be “self explaining”.
  14. The layout of the flow definition should remind the developer of source codes to shorten the learning curve.
  15. It should be possible to validate the flow definition before implementing the parts.

Last edited Apr 19, 2013 at 4:00 PM by InneHo, version 1

Comments

No comments yet.