Back in 1996 I 'discovered' a software architecture which I called Intention Architecture. Back then it was just another way to develop software that would make it manageable to write complex software. However my inspiration of coming up with Intention Architecture was bound to the very fundamental behavioural nature of human being and to the nature of human mind.
You see each one of us gets motivated into doing different things in daily life, in our social and professional life. Our motives generate our requirements e.g. my motive can be to be the best fresh food supplier. This simple motive can generate several requirements for me e.g. to make it easy for farmers to bring items to me, to manage inventory, to manage presentation etc. While in real life these requirements are met, we are not conscious how the outcome of one requirement influences the outcome of another. But none the less it is always the case
In software sphere of course the requirements are tangled and one influences another e.g. The way list of farmer names displayed in the company administration will influence how I locate the supplier of some specific food item etc... Depending on the situation and responsibility of the developers this can open a can of issues like memory constrain, responsiveness', user friendliness etc. Each such issue will turn around some distinct resources /data items like 'list of farmer names', 'list of foods for each farmer',.' memory size' etc.
Intention architecture would allow dealing with each of the issues in terms of original requirement e.g. requirement to 'display the list of names of the farmers ' is slow ' which would allow to locate the actual instruction that the requirement generates for example the allocation of memory. Without intention architecture such findings will be part of debugging the program code- what intention architecture allows is to break each requirement into a single sequence of small chunks of code in terms of use cases for the software. This way two different requirements may have two different series of chunks - where some chunks may be common. At the time of development also the developer can actually refer to the requirement as a reference point. The ability to refer to the requirement within the code also goes with events like clicking the button -so even the user actions are bound with requirement. I donor quite understand why this simple concept has not been widely accepted in the software industry.
A major drive towards Intention Architecture is the notion which is not new in software called "separation of concern" along with use case dialog reuse. However Intention Architecture has given away a number of concepts and values which are valid in the wider context of reality. I list those characteristics of Intention Architecture below and you can make the judgement whether the constructs opens up new view of reality for you.
The dictionary meaning of the word architecture is a master plan.
In software architecture, the architecture is the plan of progressing from motives to requirement to actions. Intention Architecture accomplishes this faithfully by bringing following constructs.
1 containment: a collection of terms with values Containment also provides action = intention + data. What it means containment will have certain terms having data values and intentions like e.g. find the maximum of value. The action is actual invocation of intention or function on those data values- which is function invocation within certain scope.
2. Intention Flow: a sequence of containments -
3. Value Transfer: in software are the computational flow or transfer values of variables
4. Flow Resolution: A flow in the software sense produces a desired result in the last containment of its sequence.
5. Background -flow of computation -through containments result in background to visit next containment.
The fundamental departure of Intention Architecture from the mainstream computing is reliance on the user requirement as the main spin for computation. In a typical graphical interface situation this will mean the events will tie up the requirement and use cases to containments which would represent 'listeners' in the traditional sense.
The above 5 characteristics are the building blocks of Intention Architecture.
The above five also represent something fundamental that people do - whether in business or in games -in daily life.
So if we try to map the above 5 precepts of intention architecture to reality outside software we shall come up with the following:
1. Containment is equivalent to human ability /nature of focussing to a limited few things at a time, isolating them from the rest.
2. Intention flow is equivalent to man's perception of things in flow and ability to summarise and perceive a series of containments as a whole...
3. Value transfer is the transfer of meaning of terms from one instance of containment to another.
4. Flow resolution corresponds to human way of arriving at a conclusion by sequential step through a series of containments
5. The background corresponds to the human ability to build background knowledge by learning meaning of terms in containments the being experiences.
The above sort of correspondence maps the software architecture to human basic instincts and gives a starting point of modelling human behaviour through Intention Architecture.
Designers of future internet can take some hints from this correspondence and can get some directions for future development.
If we assume every internet page is a focus i.e. containment with a collection of intentions and terms, the links between pages can act as intentions and search engines will be smarter by knowing the flow of those pages as defined in content and by mapping the intentions of those pages to the intentions of the user. Search engine can virtually act as a match maker of motives and intentions from people in different parts of the world [between author and reader of a page] and can navigate through pages which are pre-linked with intention flows that match the intentions of the user.
This will also mean search result by two people with two backgrounds will be different if their motives and intentions are different e.g. a business man and a student looking for a good place to eat will get different results because their motives and intentions and liking are different.
So far what has stopped the existing Internet technology to become smarter in the above sense is that total absence of the user's requirement and background in the computational model. In a future article I shall go deeper into this aspect and why intentions can be a good resource in the world of computation where reuse and separation of concerns are two very important pillars of software industry and its advancement.
On the other hand the new findings in noetic science reveal startling facts which will compel us not to ignore human intentions because after all they are the drivers of our actions. You can read all about the new findings from http://www.noetic.org.
Pronab Pal has been a software architect and developer working through his own company Visual Analytics for the last 23 years. Nowa days he specialises in Web Infrastructure set up and web developments and web security. Intention Architecture had been Pronobs pet project back in the mid to late ninetees. Pronab lives in Canberra with one son a daughter and his wife. Pronab holds two masters degrees one in Applied Mathematics and another in Computer science.
Pronob also devote his spare time in helping people develop their own motives and intentions into fruitful actions through http://lifeff.com.
Article Source: http://EzineArticles.com/?expert=Pronab_Pal
Back in 1996 I 'discovered' a software architecture which I called Intention Architecture. Back then it was just another way to develop software that would make it manageable to write complex software. However my inspiration of coming up with Intention Architecture was bound to the very fundamental behavioural nature of human being and to the nature of human mind.
You see each one of us gets motivated into doing different things in daily life, in our social and professional life. Our motives generate our requirements e.g. my motive can be to be the best fresh food supplier. This simple motive can generate several requirements for me e.g. to make it easy for farmers to bring items to me, to manage inventory, to manage presentation etc. While in real life these requirements are met, we are not conscious how the outcome of one requirement influences the outcome of another. But none the less it is always the case
In software sphere of course the requirements are tangled and one influences another e.g. The way list of farmer names displayed in the company administration will influence how I locate the supplier of some specific food item etc... Depending on the situation and responsibility of the developers this can open a can of issues like memory constrain, responsiveness', user friendliness etc. Each such issue will turn around some distinct resources /data items like 'list of farmer names', 'list of foods for each farmer',.' memory size' etc.
Intention architecture would allow dealing with each of the issues in terms of original requirement e.g. requirement to 'display the list of names of the farmers ' is slow ' which would allow to locate the actual instruction that the requirement generates for example the allocation of memory. Without intention architecture such findings will be part of debugging the program code- what intention architecture allows is to break each requirement into a single sequence of small chunks of code in terms of use cases for the software. This way two different requirements may have two different series of chunks - where some chunks may be common. At the time of development also the developer can actually refer to the requirement as a reference point. The ability to refer to the requirement within the code also goes with events like clicking the button -so even the user actions are bound with requirement. I donor quite understand why this simple concept has not been widely accepted in the software industry.
A major drive towards Intention Architecture is the notion which is not new in software called "separation of concern" along with use case dialog reuse. However Intention Architecture has given away a number of concepts and values which are valid in the wider context of reality. I list those characteristics of Intention Architecture below and you can make the judgement whether the constructs opens up new view of reality for you.
The dictionary meaning of the word architecture is a master plan.
In software architecture, the architecture is the plan of progressing from motives to requirement to actions. Intention Architecture accomplishes this faithfully by bringing following constructs.
1 containment: a collection of terms with values Containment also provides action = intention + data. What it means containment will have certain terms having data values and intentions like e.g. find the maximum of value. The action is actual invocation of intention or function on those data values- which is function invocation within certain scope.
2. Intention Flow: a sequence of containments -
3. Value Transfer: in software are the computational flow or transfer values of variables
4. Flow Resolution: A flow in the software sense produces a desired result in the last containment of its sequence.
5. Background -flow of computation -through containments result in background to visit next containment.
The fundamental departure of Intention Architecture from the mainstream computing is reliance on the user requirement as the main spin for computation. In a typical graphical interface situation this will mean the events will tie up the requirement and use cases to containments which would represent 'listeners' in the traditional sense.
The above 5 characteristics are the building blocks of Intention Architecture.
The above five also represent something fundamental that people do - whether in business or in games -in daily life.
So if we try to map the above 5 precepts of intention architecture to reality outside software we shall come up with the following:
1. Containment is equivalent to human ability /nature of focussing to a limited few things at a time, isolating them from the rest.
2. Intention flow is equivalent to man's perception of things in flow and ability to summarise and perceive a series of containments as a whole...
3. Value transfer is the transfer of meaning of terms from one instance of containment to another.
4. Flow resolution corresponds to human way of arriving at a conclusion by sequential step through a series of containments
5. The background corresponds to the human ability to build background knowledge by learning meaning of terms in containments the being experiences.
The above sort of correspondence maps the software architecture to human basic instincts and gives a starting point of modelling human behaviour through Intention Architecture.
Designers of future internet can take some hints from this correspondence and can get some directions for future development.
If we assume every internet page is a focus i.e. containment with a collection of intentions and terms, the links between pages can act as intentions and search engines will be smarter by knowing the flow of those pages as defined in content and by mapping the intentions of those pages to the intentions of the user. Search engine can virtually act as a match maker of motives and intentions from people in different parts of the world [between author and reader of a page] and can navigate through pages which are pre-linked with intention flows that match the intentions of the user.
This will also mean search result by two people with two backgrounds will be different if their motives and intentions are different e.g. a business man and a student looking for a good place to eat will get different results because their motives and intentions and liking are different.
So far what has stopped the existing Internet technology to become smarter in the above sense is that total absence of the user's requirement and background in the computational model. In a future article I shall go deeper into this aspect and why intentions can be a good resource in the world of computation where reuse and separation of concerns are two very important pillars of software industry and its advancement.
On the other hand the new findings in noetic science reveal startling facts which will compel us not to ignore human intentions because after all they are the drivers of our actions. You can read all about the new findings from http://www.noetic.org.
Pronab Pal has been a software architect and developer working through his own company Visual Analytics for the last 23 years. Nowa days he specialises in Web Infrastructure set up and web developments and web security. Intention Architecture had been Pronobs pet project back in the mid to late ninetees. Pronab lives in Canberra with one son a daughter and his wife. Pronab holds two masters degrees one in Applied Mathematics and another in Computer science.
Pronob also devote his spare time in helping people develop their own motives and intentions into fruitful actions through http://lifeff.com.
Article Source: http://EzineArticles.com/?expert=Pronab_Pal
The developer of the project is international exhibition company Abu Dabi (Abu Dhabi National Exhibitions Company (ADNEC).
