I generated association rules from "Create Association Rules" Operator. How do I select most interesting rule from these?
Created rules - https://ibb.co/duUoKF
It all depends on your problem. Take the ones that make sense in regards to the question and then you could sort by support, lift or confidence.
There are some 30 measures proposed for the "interestingness" of rules.
Implement one that you like.
Related
Does easy-rules support a stateful rule-engine like Drools?
I would like to re-execute other rules if the fact is updated by one of the rule.
Please let me know if this is supported by easy-rules.
No, it's not stateful.
You could implement statefulness yourself by storing state in a static structure and run rules over the state by treating it as facts whenever state changes.
By walking through a tree structure I have to check at each tree-level whether some nodes at that level fulfill certain criterials and then do some related action. Without easyrules, this can be implemented in a recursive call where nodes at each level during an iteration can be checked by if-else. How can this kind of behavior be implemented by using rule?
You can try to use an InferenceRulesEngine for that. You need to add facts for each level and register the required rules to trigger actions when a given level meets the criteria.
The inference engine will continuously select candidate rules and apply them until no more rules are applicable. So you need to make sure there is a certain fact that acts as a stop condition in your rules.
I want to add some custom rules in order to eliminate certain false positives and to add certain rules of my own (say 3 level locks should be shown as warning, uninitialized variables should not be shown as warnings, etc).
How can I add my custom rules to coverity?
It sounds like you’re asking how to write custom checkers using the Coverity Extend SDK, but actually just need to change the behavior of existing built-in checkers. The first should be well-documented behind the paywall (an onsite course is even included in some corporate deals, which is how I took it), but in my experience should be the last thing you get around to—there’s a far faster return from existing checkers.
Changing the behavior of individual checkers is covered in the documentation for their configuration options (also paywalled), though it’s not clear whether the existing options will cover what you want, in which case you may need to file an enhancement ticket and wait in hope. I cover this, probably in more generality than you care about, in my Dr Dobbs article, http://pobox.com/~flash/Deploying_Static_Analysis.pdf.
Recently, I am reading about the rule engines in JBOSS Drools Manual [ref - 2.2.5. Strong and Loose Coupling]. Below is the excerpt from it 'If your rules are all strongly coupled, the chances are that the rules will have future inflexibility, and more significantly, that perhaps a rule engine is overkill (as the logic is a clear chain of rules - and can be hard coded. [A Decision Tree may be in order]). This is not to say that strong or weak coupling is inherently bad, but it is a point to keep in mind when considering a rule engine and in how you capture the rules. "Loosely" coupled rules should result in a system that allows rules to be changed, removed and added without requiring changes to other rules that are unrelated.'
Does that mean, the rule engine is not suitable option to implement complex business logic [tightly coupled rules or chain of rules].
In my current project, we have chain of rules i.e. outcome of 1 rule decides the outcome of another rule and so on. The application has many internal variables to chain the rules. I thought rules engine might help to handle the complexity with the added advantage of declarative rules and dynamic business logic.
Discussion in this regard will be helpful ...
Some logic just isn't all that easy to get right even if you exactly know the order and nature of the tests you need to perform, and the actions that should result. Examples are Corporate Audits, Means testing for Assistance programs, Insurance regulations, etc.
Most Rules Engines today are beginning to include a Decision Table feature, which in all reality introduces some "limited strong coupling" (I don't know if that is really a term, but it is how I understand the effect in systems such as ILog, Drools, etc.). This is helpful because some tests are just related to other tests and decision tables are far better for structuring these tests than IF THEN ELSE structures.
Corticon (a proprietary Rules Engine) and DTRules (an open source Rules Engine) just toss the whole loosely coupled rules approach, and just build decision tables. The idea is that giving a nice structure for the construction of your decisions (which amount to decision trees underneath everything) is easier for many applications.
"Avoiding strong coupling" has nothing to do with "avoiding complexity".
What the documentation advocates is that you should not call one rule from another, instead, each rule should produce an outcome, and the outcome itself should trigger the next rule in chain. This way rules do not concern with what happens next, and instead they deal with facts (aha!). And if - instead of writing rules for facts - you focus on writing an ordinary flow of procedural logic, you do not really need the added complexity of a rules engine.
The difference is subtle, but not more subtle than rules like "don't put your business logic in view" or "don't put your database access code in your business logic".
In IBM ILOG Jrules there are many ways you can represent your rules.
In plain english like language , if else kind of syntax.
decision table - for a set of value
decision tree - multiple outcomes , branching out.
so you can decide on which way you can use the above three ways which fits to crack your complex rules into a more simpler form.
you can use rule flow orchestration with conditional flow to tackle " outcome of 1 rule will be the input of another rule "
I think it all depends on UI, not on actual logic that the rule(s) contain(s). Remember that most of today's engines are decision-table-mentality-based. And all that "Strong and Loose Coupling" is nothing more than buzz words used as an excuse for a bad UI or lack of it. Normal engine can handle execution of a rule of any complexity. Note that this is my personal opinion, lots of folks out there would completely disagree. So, please don't rush to downgrade my answer, I'm just trying to help :)
The typical notion is that the rule with complex logic would look really "messed up" or even impossible to implement in a decision table. Normally, guys try to combat that by dividing complex rules into smaller simple rules and stack them up into rule sets based on execution priorities.
There are new engines that have decision-table-less UIs by implementing parentheses instead of priorities. Parentheses also help with complexity.
When is a Business Rules Engine used?
What is the difference between Business Rules Engines and scripting/configuration/customization
A business rules engine, or a business rules management system, should be used when you are trying to implement a decision in your code. But not just any decision. A decision that:
Involves lots of rules
Has rules that change often
Has rules that are complex or interact in complex ways (think lots of nested IFs otherwise)
Has rules that only someone with domain knowledge can understand/verify
Is one that the business people REALLY want to be able to change without your help
Involves using predictive analytics / scores as part of the decision making
These are the kinds of decisions that pay off the use of a business rules management system. Don't start with the rules, start with the DECISIONS.
Business rules are verbose (so business people find them easier to read), declarative not procedural and atomic (so they can be stored, managed and reused like data in a database).
More on why to use business rules here in this piece on why I believe in business rules.
Business rules engines are typically used to provide customizable "IF some-condidtion THEN do-something" sorts of logic to applications. These types of business rules can trigger certain workflows to execute or bubble up event knowledge to higher level rules, causing them to be evaluated.
Using a rule engine also allows for easier separation of concerns by removing the business logic from your code. Rules engines today typically also offer a front-end where users can add new rules without having to modify scripts inside the application.
Rules engines implement algorithms such as Rete (speaking from Drools experience) that make the task of evaluating the rules quicker. The rule engine also provides forward chaining, backward chaining, hybrid chaining, etc. of rules. However, these could be implemented in a scripting language as well. You can achieve some of the same sorts of things with both approaches, but I believe that it depends on the complexity and number of rules as to which avenue you should choose.
Take a look at this link from the Jess project: http://www.jessrules.com/guidelines.shtml
It provides a step-by-step walk through of questions to ask yourself in order to determine if a rules engine meets your needs, or is overkill.
Rules engines can do forward and backward chaining as well as inferencing. Check out Fair Isaac Blaze, Drools or iLog for implementations.