Design Chunks as Software Components
A system may have several design chunks; as a system is developed ,a design chunk constantly morphs within its boundary and interacts with the outside world through well-defined intents. In the Intention space, a Design Chunk can have content in any form that makes sense to the human user. In the coding world, a single function or a collection of functions can be in a design chunk; it may have some UI/UX elements related to those functions, and there can be a prototype component to join UI/UX with functions etc. Thus the domain of operation of Design Chunks are not the numbers and strings, but they are the JSON QnA's s that make sense to a human,but is interpret-able by the machine.Intention Space takes computation progression as an act of taking a set of QnA's and producing another set of QnA's.
Instead of the traditional notion that a computation step has an input, generating an output, a Design Chunk as a software component, acts on a set of QnA's and passes QnA's to another Design Chunk as computation proceeds. The concept of 'function parameters,' a foundational element in traditional definitions of functions in computation, is looked upon as a JSON statement pairs received or produced by the Design Chunks; e.g., instead of just declaring a parameter variable called 'apple' and assigning a value, say $5 ,as the price of apple, e.g., var apple = 5 in the traditional way, Intention space equivalent will be a JSON QnA pair, represented as a JSON object: {'question':' price of apple','answer':'$5' }. Any operation in Intention Space operates over a set of JSON statement pairs or QnAs; as an operator,a Design Chunk passes QnAs to another operator Design Chunk through some rules of operation in Intention Space using two more operators. A particular set of QnAs are associated with a Design Chunk at design time.
Operators in Intention Space over QnAs Domain.
Intention Space's provides the set of operators that operate on the QnA s and sets up the rules . Three kinds of operators given by the Intention Space are : Design Chunk, Objects and Intentions ; Each Design Chunk has a name; we can refer to it as a Design Chunk Phrase; similarly an Object Phrase is an Instance of Object, and Intention Phrase is an instance of Intention . Intention Space maintains three dictionaries of phrases corresponding to each phrase category or operator type in Intention Space as defined below.
Categories Of Phrases in Intention Space
i. Design Chunk Phrases
ii. Intention Phrases
iii. Object Phrases
The word Object has special significance in Intention Space. An Object has a name, and its only behaviour/capability is to receive and reflect 'intentions'. Objects in Intention Space don't hold any custom code; they are named entities that receive Intentions from Design Chunks and reflect Intention to another Design Chunk. A received Intention can be mapped to a different reflected Intention.
As the Design Chunk names, Intents and Objects are just human-readable entities in an Intention Space, the special method of the ' Intentions and Object' based software execution model maintains an operation time-defined structural integrity that defines the run-time address space. We shall see, from a software execution perspective, these Design Chunks provide a uniquely identifiable execution boundary for any future possible use of the software App.