i use Jess rule engine with java and i have a template person with a number of facts. I excecute a rule concerning persons and i would like to get the number of facts that satisfy the rule and made it fire. Is this possible;
e.g.Command engine.executeCommand("(run)") returns only 0 or 1 in case a rule fired
Depending on what exactly you need, there are several things you might do. The function (run) actually returns the number of rules that fired, so if each fact activates one rule, then the return value of (run) would do it.
If you need to do anything more complex, then you can register a JessEventListener to be notified when each rule fires. The JessEvent will contain the whole activation record for the rule, so you can walk through it and count the facts however you like. Since rules can match the non-existence of facts, or the existence of at least one fact that fits a pattern, etc, the question of "how many facts activated a rule" isn't completely straightforward. But with the activation record in hand, you can count them however you like.
Related
I have a confusion after discussion with one of my fellow on the rule base system. I have developed one in Android which has set of rules. What i say is that initial facts have to match any rule in order to start the engine, so we can directly start matching the initial facts without sending them to working memory.
the fellow says that NO, the initial facts has to enter the working memory and then matching should start and i agree till here but he also adds that you only need to get the variables from the initial facts and then match the rules for example io have a rule
a(variable),b(constant)
Initial facts in Working memory is a(VAR_VALUE)
so will it invoke the rule
a(variable),b(constant)
if the answer is yes then we can have a lot of such rules with constant values that can be invoked even when the working memory is empty.
i need some expert opinion on the issue above, so i may do the development changes as required.
Check the predicate match first, uf same then check if the subject is variable or not. If not then match with correapong rule if both subjects same then it will match.
Rules with comstants has to match elementa of wm. Otherwise it will b infinite loop. As aingle variable can come with any number of constants.
Also use better conflict reaolution strategy.
I'm trying to write a scenario :
As a user
......
Scenario: Breaking a rule
Given:I'm an active user
When: I break the rule 'X'
Then: I should be added to rule breakers' list
Butrule breakers' list is defined in another story.
So this story is no more independent.
We can change the Then phrase to this:
Then: The rule 'X' should be breaked by me
But the behavior of my scenario doesn't seem clear enough.
More examples:
Scenario: Registration
.....
Then: I should be loged in
(While login belongs to another scenario)vs
Then: I should be registered
And the real problem comes to the action when navigation is something your stakeholders care about.
My question:
How can I have an independent scenarios which are clearer in situations like that?
If the rule breaker's list is defined elsewhere, it's part of the state in which the scenario starts, so it's a "given".
Your scenario should resemble something like:
As a user
......
Scenario: Breaking a rule
Given:I'm an active user
And: I'm not in the rule breakers' list <- Add another given
When: I break the rule 'X'
Then: I should be added to rule breakers' list
The extra "given" can reuse the same code as the other scenario, if that's useful. Alternatively, you can use a shortcut, like putting data directly into the database rather than going through the UI. It's fine for this scenario to have no knowledge of how that list comes into being, as long as there's an example of that somewhere else.
What is a "user story scenario"? User stories come and go they are not much more than a piece of paper and some discussion. After the user story is finished, it has unsignificant relevance. However, your gherkins are there to stay as automated tests and living documentation. After the user story is finished, you can deliver a new function. What is that function? Your gherkin should describe exactly that and nothing more.
In your example: ok, there might be some plans that we are also going to keep a list of rule-breakers, but let's concentrate first on the immediate user story and forget about such a list. That list might be a separate user story later on or it may never even happen. So the question is: what immediate value has my current user story, what is the functionality that the users will see. If it's just some feedback to the user along some rules, than that is what my gherkins should reflect: Given some preconditions When I'm breaking rule 'X' Than I should receive feedback this or that way.
If it is difficult to come up with sensible gherkin scenarios, chances are high that you have split up your user stories inappropriately (which BTW is not a problem, but something best found out as early as possible - which is the very reason you are using bdd.)
I am looking for an appropriate formalism (i.e. a temporal logic) to model the following kind of situation
There can be events happening at discrete events in time (subject to conditions to be detailed below).
There is state. This state cannot be expressed by a fixed number of variables. However, it is possible to express it with a linear list/array, where each entry consists of a finite number of variables.
Before any events have happened, the state is fixed.
At any point in time, events are possible. They have a fixed structure (with a few variables). The possible events are constrained by the current state.
Events will cause an immediate change of the state.
Events can also cause continuous state changes. For example, a variable (of one of the entries of the array mentioned above) changes its value from 0 to 1 over some time (either immediately or after a specified delay).
It should also be possible to specify discrete points in time in the form "the earliest point in time after event E where some condition C holds", and to start a continuos state change at such a point.
Is there an existing temporal logic to model something like this?
It should also be possible to express desired conditions, like the following:
Referring to a certain point in time: The sum of a specific variables of all the entries of the array may not exceed a certain threshold.
Referring to change over time: For all possible time intervals, the value of a certain variable (again, from each entry of said array) [realistically, rather of some arithmetic expression computed for each entry] must not change faster than a given threshold.
There should exist a model checker that can check whether for all possible scenarios, all the conditions are met. If this is not the case, it should print one possible scenario and tell me which condition is not met. In other words, it should distinguish between conditions describing the possible scenarios, and conditions that have have to be fulfilled in those scenarios, and not just tell me "not possible".
You need a model checker with more flexible language. Technically speaking model checking of systems of infinite state space is open research problem and in general case algorithmically undecidable. The temporal logic is more typically related to propreties under the question.
Considering limited info you shared about your project, why do not you try Spin/Promela it is loosely inspired by C and has 'buffers' which can be considered to be arrays. At the least you might be able to simulate your system?
I'm learning Alloy, and can use check and run individually. But, when I have them both in, it seems that the check is ignored. How do I execute both the check and the run?
To expand the question:
If I have a run, do I even need a check? Won't it automatically check all my assertions? Or is the goal of the check not only to check the assertions, but to intentionally and exhaustively (within the scope) search for a counterexample?
Is the goal of run only to find an instance that meets the predicate? Or is there another usage of run?
Perhaps check should be search-counterexample and run should be search-example?
Is Alloy limited to one search (check or run) for execution? If so, is the best practice to simply comment out all but one check/run, and uncomment out one at a time?
How do I execute both the check and the run?
You don't. You do one at a time.
Given two predicates P1 and P2, it's always possible to define a new predicate to combine them however you want (with and, or, and not, =>, etc., etc.), and doing so can be very helpful sometimes.
Given a predicate P and an assertion A, however, there may be less need to check them at the same time than you think. If the assertion A holds for a given scope, then it holds whether predicate P is satisfied or not. If it always holds in that scope, then you don't need to check it in addition to P, when seeking an instance of P. (It will hold whether you check it or not.)
If I have a run, do I even need a check? Won't it automatically check all my assertions? Or is the goal of the check not only to check the assertions, but to intentionally and exhaustively (within the scope) search for a counterexample?
An assertion is checked only when you ask the Analyzer to check it. The Analyzer checks the assertion precisely (and only) by looking for counter-examples.
In this, assertions differ from Alloy facts, which are always true by definition (or: by fiat) and need not be checked. (And more than that: they cannot be checked: since a counter-example is impossible, there is nothing for the Analyzer to look for, and there is no verb by means of which you could request that the Analyzer look for it.)
The difference between facts and assertions is worth thinking about.
Facts express constraints on a model; assertions don't. Informally, an assertion can be thought of as a suggestion (or claim) that a given constraint is already imposed on the model, that it follows logically from what has already been said. Assertions which state the blindingly obvious are useful, because checking them can draw our attention to situations where those blindingly obvious things are not in fact true. Assertions which state non-obvious consequences of the constraints in a model are also useful, in a different way, drawing our attention as readers to consequences we might have overlooked.
Facts can be useful too, as simple ways to restrict the model to situations we are interested in. But since they are always true, whether redundant with other constraints or not, facts have fewer opportunities to surprise us. (The most frequent surprise I associate with facts is the unwelcome discovery that my formulation of a fact has made it impossible to find any instances of the model. Over time, I have come to avoid using facts wherever possible: anything I am tempted to write as a fact, I end up rewriting as a predicate.)
Is the goal of run only to find an instance that meets the predicate? Or is there another usage of run?
That's the only one this user of Alloy knows.
Perhaps check should be search-counterexample and run should be search-example?
You may have a point; find-example and find-counterexample might be clearer for new users. (I wouldn't like search here, at least not without -for.) But some users' fingers may rebel at replacing a five-character command like check with a twenty-one-character equivalent.
Is Alloy limited to one search (check or run) for execution? If so, is the best practice to simply comment out all but one check/run, and uncomment out one at a time?
Not necessary; the Execute menu gives you your choice of the command to execute.
is there any way to make the rules on an Expert System be modified by the system itself so tha t it can learn from its experiences?
-suggestions are always welcome.Thanks!
The short answer is "yes" there are ways to do that. For example, the "if" part of the rule can be dependent on a numerical value (e.g., a prior probability). When the rule is triggered, the "then" part of the rule can update the prior, which changes the rule. If you are asking about structural changes to a rule, that is also possible (you could make a rule dependent on condition assertions that may be created, modified, or removed) but the extent to which that is possible will depend on the particular expert system shell you are using.