Design/Implementation decision separation
One of the main reasons for the difficulty involved in software development and the skill levels required is that conventional development involves a complex mixture of implementation decisions and design decisions. As a result, a simple change to the implementation can involve extensive source changes or may even be impractical to achieve without extensive rewriting.
As an Adapt application holds the Total Design Knowledge then the implementation decisions may be made by Adapt as required and may then be revised automatically as the design evolves. The designer is therefore relieved of much of the work that would be required with conventional software development and more importantly arbitrary limitations on the capabilities of the application are not imposed.
The implementation decisions that have to be made using conventional software cover a very wide range of issues; just a few examples are:
the choice of software tools to employ such as a database package,
where the database is to hold the data; just locally or in the cloud etc.,
how the various categories of data required by the application are to be stored at different times and for different purposes,
how individual data items are to be held,
the target processor and OS on which the application is to be run,
whether the application is to run in a browser or to be free-standing.
Typical Examples
The problem with a lot of implementation decisions is that they impose limitations upon how the application may be developed in the future. One simple example is where a designer initially chooses to implement an application using a spreadsheet as this tool allows some applications to be produced without requiring a lot of programming skills. The trouble is that over time the application may be needed to hold more data than is really practical in a spreadsheet or the structure of the data becomes more complicated as features are added. These limitations often mean that in order for the application to be developed further it has to be rewritten to use a 3GL program together with a database. Such an expensive option could be avoided if the designer did not have to make such a choice in the first place.
A more typical form of application would be one using a database to hold the data and one or more programs written in a 3GL to provide facilities to interrogate, display, analyse, modify and update the data. Because of the overhead involved in accessing the contents of a database, the applications will be designed to read values into memory once; either to global variables, local variables on the stack or to dynamically allocated memory on the heap. Then when the application wishes to display any values then they are generally written to a control object held within a window. Any altered values have then to be copied back by the same path to the database.
All this work has to be programmed even though it is really just data management/implementation tasks that the designer would prefer to not get involved in and because of the designer's involvement then any future design changes may require a lot of skilled work because of the interaction with the implementation details.
Data Path Analysis
A further, related issue is that once a value has been read into memory and possibly involved in calculations then it is essentially dissociated from its source item so that it is very difficult (often almost impossible) for a software tool to analyse the data paths within the application.
In the case of Adapt, because it has Total Design Knowledge and the Universal Storage mechanism, it is able to analyse the application and show for each dAta item, how it is derived, which other items can affect its value, the calculations involved and the situations in which they apply etc. Such an analysis is of great help to the designer in making changes or to a user learning about the application.
The analysis is able to be done at any level to give a picture of the function of a particular logic path, logic or the whole application.
Host Independence
Another example of the importance of distinguishing between decision types is the ability to develop applications that may run on a variety of hosts.
Traditionally most applications were developed for PCs and that meant either Windows, Linux or OSX were possible hosts.
With the rise of the internet then applications started to be developed to run within browsers and now most sites are essentially applications in that they contain some form of logic as well as content; e.g. any site involved in e-commerce. However, the technology used to create internet applications is totally different to that employed in PC applications.
To complicate matters further the rise of smartphones and tablets has introduced new host platforms such as IOS and Android.
At present any application that has been developed using conventional technology will need extensive work to move it from one host to another. The amount of work may be mitigated by good design, in some cases, but all will contain some implementation decisions that need to be assessed and possibly revised.
In the case of Adapt applications then as the designer only needs to consider the design decisions then applications can be moved easily to a different type of host and the appropriate changes will occur automatically. These changes will typically involve generating the code dAta for a different processor and using a different interface to the host operating system.
Obviously, there can be physical differences between different hosts; such as screen size etc. This can be accommodated automatically by scaling and scrolling dAta images but in some cases the designer will define a choice of image designs for some dAtas to be used with different screen sizes.
The important point is that Adapt technology offers the opportunity to develop host independence across a wide range of computing devices for the first time.