vldtecno / ptn-engine Goto Github PK

PTN_EngineImpl should be a nested private class from PTN_Engine.

Fix the job in TravisCI

The PTN Engine should be safe to use in a multi-threaded environment.

Create stress tests for:

• number of tokens in a place (is there some evil overflow? Is it failing "gracefully"?)
• number of places associated with a transition
• number of transitions in a net

At the moment the methods called on each place and transition are passed via shared pointer in the petri net constructor. It would be nicer to have strings instead, just like the names of the places.
The pointers to the methods would have to be loaded first and mapped into strings.
This step would make it easier to implement the feature of loading the net from some kind of text file on runtime instead of having to define it on compile time.

Implement free choice nets.
Multiple choice scenario: more than one transition is active at the same time because of a common place and after one of them fires the others can no longer fire.
The decision of which to be fired should be random. Each transition should have an equal probability of being fired.
(At the moment it depends on the order on the insertion order of transitions in the vector, so it is not random. )

This issue is about cleaning up code formatting and, correcting typos and so on.
It will never be closed.

Create a hierarchy of classes responsible for the various modes of executing actions associated to each place.

It will simplify the API and it will probably improve performance. It will also add more flexibility in choosing which functions could be invoked by the Petri net.

Remove Action ActivationCondition, IConditionFunctor and IActionFunctor and use instead std::function and bind in order to use member functions.

Improve the introduction text.

On activation a transition may require more than one token from one of its activation places to fire. This number is the activation weight.
After firing, the destination places might also receive a variable number of tokens. This number is determined by the destination weight.
Usually this is represented in the arcs connecting a place to a transition, but I expect that this can be implemented in the transition class and that there is no need to create an "Arc" class.

The Petri net should be able to be permanently running while listening to events and reacting accordingly.
To implement this, the net should be running in a separate thread.

It should be possible to create a Petri net on start-up by importing it from a configuration file. It should also be possible to export an existing Petri net to an xml configuration file.
For now xml will be supported, but it should be possible to extend it to other formats.

No XML validation is necessary at the moment.

Adding a token in an input place should call the action for that place.

Calling execute (maybe it should be called "run" instead) should spawn a new thread and the engine should be running on its own thread. It should stop when flagged to stop and it should sleep if there is transition ready to fire.
Actions to be executed "onEnter" and "onExit" should be executed in a new thread or in a dedicated separate thread (something like a job queue thread), not to block the execution of the engine.

Hello，
I would like to know if it is possible to create a multi-threaded Petri with locks using this tool.
or
Can I add these functions myself?

Precondition that a transition may only fire when an activation place is empty.

Create a simplified elevator controller using the PTN-Engine in the examples.

Add a clang-format specification to be used with the c++ code.

Add the possibility of recording and replaying API calls to/from a stream.

Currently Travis CI is only building. The next step is to get a build of googletest into the build machine and to have the PTN Engine tests running there.

There are some warnings in Visual Studio 2015 C4275, because of the error hadling classes inheriting from std::runtime_error not being exported, while these error classes are.
I should not be a big problem to ignore this warning.

https://msdn.microsoft.com/en-us/library/3tdb471s.aspx

The latest version of this topic can be found at Compiler Warning (level 2) C4275.

non – DLL-interface classkey 'identifier' used as base for DLL-interface classkey 'identifier'

An exported class was derived from a class that was not exported.

To minimize the possibility of data corruption when exporting a class with __declspec(dllexport), ensure that:

All your static data is accessed through functions that are exported from the DLL.

No inlined methods of your class can modify static data.

No inlined methods of your class use CRT functions or other library functions use static data.

No inlined class functions use CRT functions, or other library functions, where, for example, you access static data.

No methods of your class (regardless of inlining) can use types where the instantiation in the EXE and DLL have static data differences.

You can avoid exporting classes by defining a DLL that defines a class with virtual functions, and functions you can call to instantiate and delete objects of the type. You can then just call virtual functions on the type.

For more information on exporting templates, see http://support.microsoft.com/default.aspx?scid=KB;EN-US;168958.

C4275 can be ignored in Visual C++ if you are deriving from a type in the Standard C++ Library, compiling a debug release (/MTd) and where the compiler error message refers to _Container_base.

// C4275.cpp
// compile with: /EHsc /MTd /W2 /c
#include
using namespace std;
class Node;
class __declspec(dllimport) VecWrapper : vector<Node *> {}; // C4275

GCC is lagging implementing this feature. For the time being a regular mutex will be used instead.

When a transition is fired it will take all tokens present in an activation place, connected to it via a reset arc.

An easy implementation for this is to use the value 0 on the weight of the activation arc.

Using the value 0 for weights on the destination arcs should still be an error.

Current CMake scripts are not using CMake to its best potential. This needs to be improved.

• use find_package for googletest
• make the PTN Engine findable by CMake
• etc

Add the possibility of having timed transitions.

Specify standard procedure to evaluate test coverage and publish results.

Improve unit tests so that they better reflect the requirements of each component.

Select and use one of the unit test naming conventions mentioned here: https://dzone.com/articles/7-popular-unit-test-naming

MethodName_StateUnderTest_ExpectedBehavior: There are arguments against this strategy that if method names change as part of code refactoring than test name like this should also change or it becomes difficult to comprehend at a later stage. Following are some of the example:
    isAdult_AgeLessThan18_False
    withdrawMoney_InvalidAccount_ExceptionThrown
    admitStudent_MissingMandatoryFields_FailToAdmit
MethodName_ExpectedBehavior_StateUnderTest: Slightly tweeked from above, but a section of developers also recommend using this naming technique. This technique also has disadvantage that if method names get changed, it becomes difficult to comprehend at a later stage. Following is how tests in first example would read like if named using this technique:
    isAdult_False_AgeLessThan18
    withdrawMoney_ThrowsException_IfAccountIsInvalid
    admitStudent_FailToAdmit_IfMandatoryFieldsAreMissing
test[Feature being tested]: This one makes it easy to read the test as the feature to be tested is written as part of test name. Although, there are arguments that the “test” prefix is redundant. However, some sections of developer love to use this technique. Following is how the above tests would read like if named using this technique:
    testIsNotAnAdultIfAgeLessThan18
    testFailToWithdrawMoneyIfAccountIsInvalid
    testStudentIsNotAdmittedIfMandatoryFieldsAreMissing
Feature to be tested: Many suggests that it is better to simply write the feature to be tested because one is anyway using annotations to identify method as test methods. It is also recommended for the reason that it makes unit tests as alternate form of documentation and avoid code smells. Following is how tests in first example would read like if named using this technique:
    IsNotAnAdultIfAgeLessThan18
    FailToWithdrawMoneyIfAccountIsInvalid
    StudentIsNotAdmittedIfMandatoryFieldsAreMissing
Should_ExpectedBehavior_When_StateUnderTest: This technique is also used by many as it makes it easy to read the tests. Following is how tests in first example would read like if named using this technique:
    Should_ThrowException_When_AgeLessThan18
    Should_FailToWithdrawMoney_ForInvalidAccount
    Should_FailToAdmit_IfMandatoryFieldsAreMissing
When_StateUnderTest_Expect_ExpectedBehavior: Following is how tests in first example would read like if named using this technique:
    When_AgeLessThan18_Expect_isAdultAsFalse
    When_InvalidAccount_Expect_WithdrawMoneyToFail
    When_MandatoryFieldsAreMissing_Expect_StudentAdmissionToFail
Given_Preconditions_When_StateUnderTest_Then_ExpectedBehavior: This approach is based on naming convention developed as part of Behavior-Driven Development (BDD). The idea is to break down the tests into three part such that one could come up with preconditions, state under test and expected behavior to be written in above format. Following is how tests in first example would read like if named using this technique:
    Given_UserIsAuthenticated_When_InvalidAccountNumberIsUsedToWithdrawMoney_Then_TransactionsWillFail

At the moment the methods called on each place and transition are passed via shared pointer in the petri net constructor. It would be nicer to have strings instead, just like the names of the places.
The pointers to the methods would have to be loaded first and mapped into strings.

Add the possibility to register the methods to be used in the Petri net. The purpose is that actions and conditions could be accessed on runtime through an identifier.
This step will facilitate configuring the net through a script loaded on initialization.
The user will still have to register and provide identifiers to the condition and action methods on compile time.

Improve/guarantee the thread safety of the PTN-Engine.