## 3 The Notification-Oriented Paradigm
### NOP Inference Chain  
The following items explain the NOP entities according to the inference chain, taking into account Figures 2 and 3:  
* Fact Base Element (_FBE_): Entity (e.g., an instance of a type or class) that contains the notifier _Attributes_ and inciteful _Methods;_
* _Attribute_: Entity that is responsible for storing a value that represents property states of an _FBE_ and can precisely notify related _Premises_ when their value changes;
* _Premise_: Entity that, after being notified by an _Attribute_, compares that _Attribute_ with another _Attribute_ or a constant via a logic-relational operator (e.g., \(=\), \(\
eq\), \(>\), \(<\)), and subsequently, notifies related _Condition_ when its logical state changes;
* _Condition_: Entity that groups one or more _Premises_ and, when notified by any of them, performs a logical operation (e.g., conjunction or a disjunction) over their states and notifies its concerned _Rule_ if its logical value changes;
* _Rule_: Entity with a _Condition_ and an _Action_ that determines the execution of its _Action_ when its _Condition_ is approved (e.g., its logical state is true);
* _Action_: Entity that, when instigated by its _Rule_, activates its _Instations_ to execute its functions, properly parametrizing them if necessary;  
Figure 3: Notification flows.  
Figure 2: NOP inference chain.  
* _Intigation_: Entity related to one or more _Actions_ that, when instigated by an _Action_, instigates a set of _Method_ entities to execute, properly parametrizing them if necessary;
* _Method_: Entity that, when instigated by an _Intigation_, executes a function or service of a _FBE_ and, therefore, may change the states of _Attributes_, thereby feeding a notification inference cycle.  
The NOP organization reduces or even eliminates some of the issues concerning classical development paradigms, such as the Imperative Paradigm (IP) and Declarative Paradigm (DP), which, respectively, and even notably, include OOP and Rule-Based Systems (RBS) [16; 57]. Examples of those issues are the often strong coupling of code parts and the related structural and temporal redundancies concerning logical-causal evaluation processing [57].  
Structural redundancies occur when a given logical and/or causal evaluation is unnecessarily repeated elsewhere in the code. In turn, temporal redundancies occur when a given logical and/or causal evaluation is unnecessarily re-executed over time, and the data involved in this calculation did not change since its last execution. These problems frequently happen, for example, in nested loops in IP languages that usually tend to cause code coupling, thereby making it more challenging to achieve processing parallelism and distribution [16; 18; 22].  
The problems mentioned above do not happen in NOP since the precise notifications, e.g., between _Attributes_ and _Premises_, avoid temporal redundancy. Furthermore, the _Conditions_ sharing _Premise_ collaborations avoid structural redundancy. In this sense, NOP differs from OOP approaches because it is not loop-oriented, and NOP differs from rule-based approaches because it is not based on a monolithic factual search-oriented inference engine [16; 18; 19; 22].  
To summarize, the NOP Inference Chain allows software development with three elementary properties [16]:  
1. High-level rule-oriented modeling and programming, which helps easiness in some software/system development [59].
2. Avoidance of structural and temporal redundancies, which allows achieving proper system performance [64].
3. Implicit entity decoupling, which can favor parallel and/or distributed computing [65].  
More detailed information about the NOP and its extensive research can be found in [16; 25; 58; 66].