Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I'm designing a simple rule engine. Let me start by giving an overview.
The engine is initialized with a configuration file which specific the rules to be run and also parameters that are intended to be used by these rules.
Example:
I have a incoming order object and I will would like to do some sanity check on it like
the order quantity cannot be greater than some quantity X ( x is passed as a parameter to the engine. ) This is a simple example of a parameter being passed.
A complex example:
Some order Type.Some region.Some desk.Order Quantity = X
Some order Type.Some region.Some desk.Some trader.Quantity = y.
Some order Type.Some region.Some Product.Daily Volume = A
Some order Type.Some region.Some desk.Daily Volume = B
A lot of parameters like these are used to initialize the engine which are intended to be used by the rules.
Question:
How should these initialization parameters be passed to API ? -- JSON , XML ???
What is the best software design practice to represent and process and store these parameters so that the rules can use this information ( like what's the quantity allowed for a trader group ? to do sanity checks on the incoming order object )
I'm planning to implement this in C++
Thanks in advance
Before jumping into creating a new rules engine you should really be aware of the complexity involved e.g. Rete Algorithm this makes sense if you plan to maintain over thousands of rules because from those numbers and up if you evaluate the rules sequentially it becomes prohibitive performance-wise, and performance is particularly important in a trading system. I would actually research and explore reusing an existing rules engine e.g. CLIPS, drools, JRules etc.
Another promising possibility is to embed some sort of scripting language within your process (usually possible in e.g. Java) that can access your in-memory domain model e.g. embed a Python interpreter and use it as your "rules engine". If you absolutely must implement your own then you can use yacc and lex but last time I used it I remember it wasn't really fun and you have to be aware of the complexities i.e. scalability might become an issue if you plan to have thousands or more rules.
For rule management i.e. book keeping, editing, annotating, versioning etc you will want XML and put the actual rule under a CDATA element.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I am very sorry for the long explanation, but it is required for proper understanding.
I am working on computer vision algorithms for industrial tasks. Computer vision algorithms tend to be very complicate. Usually they involve calls for dozens (at the very least) of simpler algorithms (that are not simple either). Those calls form certain hierarchy: bigger tasks call some smaller ones, which in turn call even smaller ones, and so on.
Let’s take for example typical computer vision task: find object in image under certain conditions. This is a task that should be performed in dozens of different applications. Each application has its own set of conditions and thus it is impossible to create single algorithm that works for all of them. But they are pretty similar. Usually it is enough to replace one or two lower level functions. For example: use different method for detection of points of interest in image.
And here comes a problem: for each new application I had to copy whole code from one of the existing applications and adapt relevant parts, which is a bad practice. I am trying to eliminate those duplications by creating system of algorithms that can be used in all application without changing the code itself. Here is the list of issues system had to deal with (at least the ones I identified so far):
1) Arguments provided to main algorithm should be able to set the 'algorithmic flow' inside the system, i.e. they determine what lower level algorithms are used and how
2) Different sub-algorithms that perform same task may require different inputs. One may need an array of ints, another requires pair of double, and so on... Algorithms on the higher level should be oblivious to replacement of one sub-algorithm with another. That means they should not be aware of what arguments they receive and pass down to sub-algorithms. Same true for output of sub-algorithm. It may vary if different combination of sub-algorithms is used
3) The system must be extendable. If new sub-algorithm became available (for example: yet another way to find points of interest) the system should be able to call it. I understand that changes might be unavoidable at this point, but I would like to keep them at minimum. And in any case the system should be able to work at the same way with previous sets of arguments.
4) System must be debuggable. End user of the system should have reasonable way to dump debug information about the 'algorithmic flow' in his system, so that algorithm developer will be able to recreate the situation. It is not that trivial considering requirement (3).
5) There should be reasonable way to make sanity check for the flow of algorithms.
6) I am not going to throw exceptions but there should be reasonable way to return success / fail status of each algorithm. Again it is not easy because of requirement (3).
7) This one is more 'good to have' rather than 'must have', but it may be important. Some calculations may be performed by multiple sub-algorithms. For example calculation of gradients in image may (or may not) be required for multiple different tasks. It is good to have an option to store results of those calculations in order to reuse them later.
I created some kind of solution to this but it is far from being good. Do you have any recommendations about how this should be done?
Used language: C++
Thanks you
I'd just use some tried and true design patterns.
Use a strategy pattern to represent an algorithm that you may wish to swap out for alternatives.
Use a factory to instantiate different algorithm (strategy) instances based on some input parameter or runtime context - I'm a fan of the prototype factory where you have "inert" instances of each object in some lookup table, and based on a key you pass in you can request a clone of the one needed. I like it mainly because it's easiest to extend - you can even add new configured prototype instances to such a factory at runtime.
Note that the same "strategy" model does not have to serve for everything - it sounds like you might have some higher-level/fuzzy operations which then assemble or chain together low-level/detailed operations. The high level operations could be one type of abstract object while the detailed algorithms are the more concrete strategy instances.
As far as the inputs to the various algorithms, if it varies a lot from algorithm to algorithm you could use an extensible object like a dictionary for parameters so that each algorithm can use just the parameters it needs and ignore the others for an operation. If the dictionary is modifiable during the operation this would also permit upstream algorithms to add parameters for downstream algorithms. Key-value pairs are pretty easy to dump to a log or view in a debugger.
If each strategy instance has a unique semantic identifier you could easily debug the algorithms that get instantiated and chained together. (I use an audio DSP library that has a function to dump a description of the whole chain of configured audio processors, it's very handy).
If you use a system with strategy patterns and extensible parameters you should also be able to segregate shared algorithms from application-specific algorithms, but still have the same basic framework for instantiating and running them.
hth
I'm going to assume that you are a competent OO programmer with good domain knowledge, and your problem is more about a higher level of organisation of software components (implementing algorithms) than OO generally provides.
The patterns mentioned by #orpheist make perfect sense. Consider them. They will not solve all the problems you list. You should also consider the following.
In what form will the data be for algorithms to access?
Will you need adapters to connect one component to another?
Do you pass the data to the component or the component to the data?
Do you want to assemble a pipeline or group of components to build higher ones, which can then be applied to the data?
Do you need a language (XML, DSL) to express connections and to allow for easy experimentation?
Is performance a dominant issue already, or can you afford more interpretive techniques at this stage?
It think you need to refine some of your questions and provide some more concrete specifics. I also think your questions would be a better fit on programmers.stackexchange than here.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I need to make a state machine for a hardware device. It will have more than 25 states and I am not sure what design to apply.
Because I am using C++11 I thought of using OOP and implementing it using the State Pattern, but I don't think it is appropriate for the embedded system.
Should it be more like a C style design ? I haven't code it one before. Can someone give me some pointers on what is the best suited design ?
System information:
ARM Cortex-M4
1 MB Flash
196 KB Ram
I also saw this question, the accepted answers points to a table design, the other answer to a State pattern design.
The State Pattern is not very efficient, because any function call goes at least through a pointer and vtable lookup but as long as you don't update your state every 2 or 3 clock cycles or call a state machine function inside a time critical loop you should be fine. After all the M4 is a quite powerful microcontroller.
The question is, whether you need it or not. In my opinion, the state pattern makes only sense, if in each state, the behavior of an object significantly differs (with the need for different internal variables in each state) and if you don't want to carry over variable values during state transitions.
If your TS is only about taking the transition from A to B when reading event alpha and emitting signal beta in the process, then the classic table or switch based approach is much more sensible.
EDIT:
I just want to clarify that my answer wasn't meant as a statement against c++ or OOP, which I would definitly use here (mostly out of personal preference). I only wanted to point out that the State Pattern might be an overkill and just because one is using c++ doesn't mean he/she has to use class hierarchies, polymorphism and special design patterns everywhere.
Consider the QP active object framework, a framework for implementing hierarchical state machines in embedded systems. It's described in the book, Practical UML Statecharts in C/C++: Event Driven Programming for Embedded Systems by Miro Samek. Also, Chapter 3 of the book describes more traditional ways of implementing state machines in C and C++.
Nothing wrong with a class. You could define a 'State' enum and pass, or queue, in events, using a case switch on State to access the corect action code/function. I prefer that for simpler hardware-control state engines than the classic 'State-Machine 101' table-driven approach. Table-driven engines are awesomely flexible, but can get a bit convoluted for complex functionality and somewhat more difficult to debug.
Should it be more like a C style design ?
Gawd, NO!
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I'm creating REST API that will be used by a web page.
There are several types of data I should provide, and I'm wondering what would be the best practice:
Create one method that will return a complex object with all the needed data.
Pros: one call will be needed from the UI side to get all the data.
Cons: not generic solution at all.
Create multiple autonomous method.
Pros: generic enough to be used in the future by other components.
Cons: will require the UI to make several calls to the server.
Which one adheres more to best practices?
It ultimately depends on your environment, the data-size and the quantity of methods. But there are several reasons to go with the second option and only one to go with the first.
First option: One complex method
Reason to go with the first: The HTTP overhead of multiple requests.
Does the overhead exist? Of course, but is it really that high? HTTP is one of the lightest application layer protocols. It is designed to have little overhead. It's simplicity and light headers are some of the main reasons to its success.
Second option: Multiple autonomous methods
Now there are several reasons to go with the second option. Even when the data is large, believe me, it still is a better option. Let's discuss some aspects:
If the data-size is large
Breaking data transfer into smaller pieces is better.
HTTP is a best effort protocol and data failures are very common, specially in the internet environment - so common they should be expected. The larger the data block, the greater the risks of having to re-request everything back.
Quantity of methods: Maintainability, Reuse, Componentization, Learnability, Layering...
You said yourself, a generic solution is easier to be used by other components. The simpler and more concise the methods' responsibilities are, the easier to understand them and reuse them in other methods it is.
It is easier to maintain, to learn: the more independent they are, the less one has to know to change it (or get rid of a bug!).
To take REST into consideration here is important, but the reasons to break down the components into smaller pieces really comes from understanding the HTTP protocol and good programming/software engineering.
So, here's the thing: REST is great. But not every pattern in its purest form works in every situation. If efficiency is an issue, go the one-call route. Or maybe supply both, if others will be consuming it and might not need to pull down the full complex object every time.
I'd say REST does not care about data normalization. Having two ways to get at the same data is not going to hurt.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I m not an experienced programmer so please bear with me. As a consequence I will need to be specific on my problem which is about building an architecture to represent a power plant hierarchy:
Indeed, I m trying to construct a flexible architecture to represent contracts and pricing/analysis for multiple type of power plants. I am reading the alexandrescu book about generic design patterns and policy classes as it seems to me a good way to handle the need for flexibility and extensibility for what I want to do. Let s detail a bit :
Power plant can have different type of combustible to run (be of different types) : coal or gas or fuel. Among each of those combustible, you can choose among different sub-type of combustible (ones of different quality or Financial index). Among those sub-types, contract formula describing the delivery can be again of different types (times series averaged with FX within or via a division,etc...) Furthermore, you can be in europe and be subject to emissions reduction schemes and have to provide co2 crédits (enters in the formula of your margin), or not which depend on regulatory issues. As well, you can choose to value this power plant using different methodology etc... etc...
Thus my point is you can represent an asset in very different way which will depend on regulation, choices you make, the type of contracts you agree with another counterparty, the valuation you want to proceed and CLEARLY, you don't want to write 100 times the same code with just a little bit of change. As I said in the beginning, I am trying to find the best programming techniques to handle my program the best way. But as I said, I m new in building software achitecture. It appears to me that Policy classes would be great to handle such an architecture as they can express the kind of choices we have to make.
However, putting it in practice makes me headache. I thought of a generic object factory where Powerplant* is my abstract type where functions like void price() or riskanalysis() would be pure virtual. Then I would need to make a hierachy based on this and derive elements
I couldn't really get what do you want, but I think you should learn programming before you want to do anything related to programming.
Learning is hard and takes a lot of time but it's worth. Also, more useful than asking and getting the answer without explaination. ;)
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
In the company I work at we're dealing with a huge problem: we have a system that consists in several units of processing. We made it this way so each module has specific functionality. The integration between these modules is done using a queue system (which is not fast but we're working on it) and replicating messages between these modules. The problem is that this is generating a great deal of overhead as four of these systems are requiring the same kind of data, and maintaining consistency for these modules is bad.
Another requirement for the system is redundancy, so I was thinking to kill these two problems in one shot.
So I was thinking of using some kind of shared resource. I've looked at shared memories (which are great but could lead to locking inconsistencies if the module crashes leading to inconsistencies in the program), and maybe do some "raw copy" from the segment to another computer to do redundancy.
So I've began to search for alternatives, ideas and something like that. I've found one that is noSQL, but I don't know if the speed that I'm requiring would suffice this.
I need something (ideally):
Memory-like fast
That could provide me redundancy (active-passive is ok, active active is good)
I also think that shared-memory is the way to go. To provide redundancy, let every process copy the data that is going to be changed to local/non-shared memory. Only after the module has done its work, copy it back to shared memory. Make sure the 'copy-to-shared-memory' part is as small as possible and nothing can go wrong while doing the copy. Some tricks you could use are:
Prepare all data in local memory and use one memcpy operation to copy it to shared memory
Use a single value to indicate that the written data is valid. This could be a boolean or something like a version number that indicates the 'version' of the data written in shared memory.