 |
|
|
Invention of Interchangeable Code-blocks For the Components | |||||||||
|
This document provides very basic introduction to Pioneer-soft’s component based software development process. This process contains three basic steps: | |||||||||
| |||||||||
|
Creation of a ‘code-block’ for a component: One may use tools such as Adobe illustrator or any visual-editors tools to manually create necessary XHTML, Flash, XAML or SVG code to display a stock quote in a table, such as the one shown in the Figure#1. Once satisfied with the image, one may save the component’s ‘code-block’ in a file. I am doing nothing fancy. All I am doing is going to Yahoo finance and finding the stock quote and using the numbers to create code-block to display a table to show static-data. Likewise, please assume, created 2 more ‘code-blocks’ to display the 2 chart images shown in the Figures#2 and Figures#3; and saved each ‘code block’ in a file. If one opens each file in a browser, he should see respective components (see Figs 1-3). | |||||||||
| Figure#1 | |||||||||
|
| |||||||||
| Figure#2 | |||||||||
|
| |||||||||
| Figure#3 | |||||||||
| |||||||||
|
Assembling the 'code-blocks' (i.e. Composition of components): Now let’s see how one could compose the components. It is as simple as literally assembling the ‘code-blocks’, if the ‘code-blocks’ are properly created (i.e. conforming to certain requirements). The following pseudo code (Figure#4) provides a simple example, how one may literally assemble the ‘code-blocks’ to build a larger ‘code-block’ (for a container-component): | |||||||||
| |||||||||
|
To compose the components, all I am doing is literally coping the ‘code-blocks’ of the respective components. All one needs to do is just 'copy' the code-blocks from respective files and 'paste' at line numbers 3, 7 and 11 respectively. Isn’t it simple? The result is again a ‘code-block’ for a container component. The image for the code-block for the container-component is shown in the figure#5. | |||||||||
| Figure#5 | |||||||||
|
| |||||||||
|
Coupling of the components: If any two components in the container component needs to collaborate or exchange data, we must create coupling code. It is impossible to avoid coupling between two components, if they need to collaborate with each other. In CBSDF, each coupling is nothing but, one component calling a service-function of the other component to request its service. The components exchange data through the parameters of the service-function. One may manually implement necessary coupling code between lines 14 and 17 in the ‘code-block for the container-component. The resultant code-block for the container-component could be as shown in figure#6. | |||||||||
|
Figure#6 | |||||||||
|
| |||||||||
|
If we open the file that contains the code-block for the container component, it displays all three components as shown in the figure#7. One important advantage of this process is that, the resultant code-block is again a 'ready-to-assemble' component. | |||||||||
|
Figure#7 | |||||||||
|
| |||||||||
|
What is the use of the webpage? Absolutely useless! Unless each component is custom created using real-time-data to meet the user's unique needs based on his preferences and privileges etc. Although it is lame container-component, it is absolutely valid and outstanding example for "Component-Composition". (P.S: Please see below that the 'ready-to-assemble' parts are essential to invent 'Component-based' systems). | |||||||||
|
OK! How can we make it more useful? It is quite simple: Employ ‘Component Factory’ indirection to dynamically custom build ‘code-block’ for each component. Please visit the webpage for our 'loosely-coupled' component-orienteer programming process. | |||||||||
| |||||||||
|
To accomplish our CBSDF, the ‘code-blocks’ must have few unique characteristics (discussed in the reusable GUI-Class section), so that, they are very easy to assemble. The 'code-blocks' may be literally included in the source code for the web application. | |||||||||
|
There are thousands of mashups floating on the web. Many of them are good examples for 'replaceable code-blocks', except couple of simple features such as (a). We must employ a means to avoid variable name collision between any two mashups in each webpage, (b). If any two mashups need to collaborate or exchange data with each other, we must employ a means to include communication code (i.e. coupling code). | |||||||||
|
The resultant mashup (i.e. container code-block in fig#6) created by assembling such code-blocks must be a replaceable code-block. Hence, the container code-block can be assembled as a subcomponent to build even larger mashup, so on. This capability allowed us to build Component-hierarchies and arrays. It led to the invention of our 'Component-oriented' programming comparable to the product-manufacturing. | |||||||||
|
The XML graphics languages (e.g. XAML, SVG) have unique characteristics to build the readily interchangeable code-blocks. This website has many examples to prove that it is possible to build any GUI component in the planet using the XML languages. Unfortunately, it is hard to build such 'highly-cohesive readily-replaceable contiguous-code-blocks’ and component-hierarchy using the traditional programming languages (e.g. C++ or Java). The
interchangeable 'code-block' is the missing link for inventing processes to build applications
by assembling interchangeable parts.
This may be the reason no one else yet invented 'Component Oriented Programming'.
Please try to create the component composition (shown in Listing#1) in any traditional programming languages. The code for each component must be contiguous and composition must also result in contiguous code-block (Fig#6). This is essential to build the component-hierarchies. To see sample hierarchies, click here and please visit links at line numbers 6 to 12. Please install Adobe's SVG viewer, if you can't see interactive SVG-chart components. I hope the above experiment gives sufficient proof: It is unlikely you could create such interchangeable code-blocks for components of any consequential value using the traditional programming languages. If you could, I am sure you will agree, they are few junk exceptions that prove the point: No one can build a viable process based on few exceptions. On must invent a general process that can address even unique problems. Pioneer-soft's GUI-API processes could help developers create a replaceable ‘code block’ for any GUI component in the world. These replaceable software components have no limitations and exceptions to satisfy the unique needs of the application. In fact, it is easier to create more complex flexible GUI components than possible on any other GUI platforms such as Windows/VC++ or Java/Swing. Contrary to misconception, it is not practical to build replaceable ‘code-blocks’ for larger loosely coupled parts in the traditional programming languages. But most researchers jump to the conclusion based on false assumptions and not based on facts. They must show replaceable ‘code-blocks’ for the loosely coupled parts, if they don't agree with us. Is there any room for prejudice or unsubstantiated assumptions in research? Unfortunately, it is the biggest hurdle, I don't know how to overcome, except challenging them to substantiate their assumption and hope commonsense prevails. If we can build 'replaceable-containers’ for each and every component in the application, then it is possible to organize the whole application as a hierarchy of quickly replaceable ‘loosely-coupled’ software parts. Please click here and see important figure-3. If the entire application can be build by hierarchically assembling simpler replaceable parts, why any one in the world designs applications it any other way? | |||||||||
|
This website contains examples to prove that, our process to build larger and larger code-blocks (e.g. mashups) and eventually the applications, has no limitations or exceptions. Absolutely there is no magic here, if you know 2D/3D languages such as SVG or XAML. The interchangeable parts could have far reaching implications, comparable to the introduction of the 'interchangeable parts' around 1809, which revolutionized the 19th century manufacturing and led to the great 20th century invention, the moving assembly-line. Invention of the assembly-line revolutionized the manufacturing, which were not possible without the earlier invention 'interchangeable' parts. Therefore, we invented the missing link: independently re-designable and dynamically-customizable interchangeable software parts, which could facilitate automated assembling of the complex software applications. (See Figs) | |||||||||
|
Welcome to the 21st Century Software! The pivotal event in the history of modern industrial evolution is the invention of interchangeable-parts in early 19th century. It is not possible to build interchangeable parts using the current programming languages. So the software-makers stuck in 18th century. Fortunately, we invented processes for building 'customizable-interchangeable' parts using the emerging languages and also mechanisms for assembling the parts. The assembly lines also evolved since the early Henry Ford’s assembly-line. They no longer building model-T (e.g. one size fits all - one can have any color as long as it is black). We must invent the assembling mechanisms with the full knowledge of the modern assembly-line concepts, such as, just-in-time and Jodika/autonomation etc. However, we must also recognize that the software parts can be far more superior to the dumb metal pieces. Since we can use innovative intelligent software parts, it is a sin, if we settle for just blind emulation of the manufacturing assembly-line processes. Of course, this website has examples of our earlier assembling processes, which successfully emulated the manufacturing assembly-line. I hope, I will be able to remedy the sin. In my secret projects, I have been struggling to find such solutions and may already have found useful processes. But need costly development to validate, which I cannot afford and one-man/myself cannot build. I got to find cheaper solutions. | |||||||||
|
|||||||||
We request you
to verify this:
