I've been developing a piece of software that takes rules of the form 'A Disallows B' or 'X Requires Y' to make an application that will allow you to configure a complex item.
To describe it more fully, imagine you've got a level of folders, which have some number of sub-folders, and each of those sub-folders has some number of items. The intent is to express relationships between the items in a way that helps the user create a valid collection of selections.
So the actual rules look more like 'All(A, B, C) Disallows Any(X, Y, Z)', which states that if the user selects A, B, and C, they can't select any of X, Y, or Z. It's basically just boolean logic.
There are additional types, like those that say if you select A then you must also select B, but it's not worth getting into the specifics of all that.
It's not business logic (at least not in the normal sense), and the rules can change any time (and they will) so they need to be read from a string and interpreted or hooked up through a convoluted database structure (which I'd prefer to stay away from).
The real point is: Is there some sort of system or framework out there that deals in this kind of runtime behavior? I know that Oracle has a thing called the "Oracle Configurator" that does exactly what I'm talking about, but it's prohibitively expensive I think.
The project is almost over, and I've built a "working" system, but I'm trying to do a post-mortem to see if it could have been done better/faster/cheaper.
You might be interested in Prolog.
I believe Oracle Configurator is only a module inside E-Business Suite. It's not something you can just load into an existing database and application.
You might want to check out DBMS_RULE to see if that will do what you want.
Sterling Configure, Price, Quote, SAP Configurator and Oracle Configurator are some of the options out there.
Related
I want to make a basic library management system in prolog. The program should answer queries like which book is issued by which student and which date book will be returned. I want guidance in terms what exact components i need to learn for it (as I am very much new to prolog), i wanna develop it rapidly as i dun have time to learn the whole thing. I will be using visual prolog 7.3
Thanks in Advance
MGD
You haven't given us much of an idea what your programming background is, so I've interpolated a couple of comments below to suggest what existing experience might help in doing parts of the Visual-Prolog application asked about.
With Visual-Prolog you have to begin with user-interface design, something that I frankly found discouraging for playing around with the Prolog coding. Think of the "window" elements you want: perhaps an input field to input a user name and another input field to enter a book title, with some buttons for "search" as your "program should answer queries" spec suggests. The output will contain information about whether a book is checked out, when it is due, etc.
Then the functional part of your design can begin. Visual-Prolog asks you to declare certain things: domains (equivalent to datatypes in other languages) and predicates (the names relations and the domains to which their various arguments apply, roughly the equivalent to routines in other languages).
Your library application sounds like it is similar to a database, a "knowledge-base" containing information about users, books, and the relationship between them (e.g. this user has this book checked out), possibly with some history (who checked out a book when, and when was it returned).
Since you want to "develop it rapidly", you will probably want to start with a very simple set of domains and predicates. Perhaps "user" and "book" are the basic domains to start with, and checkOut/2 the basic predicate (indicating the fact that a particular user currently has the particular book). Then you will probably need to add (at least) the feature of storing the book's return date. This kind of design will be easier if you've done some relational database development before.
Connecting the user-interface (UI) to the "knowledge-base" of library users & books is a matter of writing predicates that serve as event-handlers for the visual elements of the UI. This is somewhat easier if you are familiar with Visual Basic. In any case you can "stub out" the event handlers while you are building the "look and feel" part of the UI, replacing them with substantive implementations as your design moves into developing the "knowledge-base".
I need to develop a user interface for inputting something like "if x or (y and z) then do a, b, and c". The data to be entered itself is already quite complicated, how do you wrap it up in an intuitive UI?
Here's my answer from a similar question: Intuitive interface for Composing Boolean Logic?
I would break your interface into two parts: the condition and the result.
Here's an example of the conditional interface:
A Few Thoughts
The interface starts out simple
If it gets complicated, it's because the user built it step by step
No editing or drag/drop - just creating and deleting branches
Conditions are a simple dropdown in this example, but could be more complicated or possibly negated. Basically this interface lets you compose expressions.
I think it's a good idea to avoid this type of interface if possible
Here is an example of how I solved the problem for a bug database. This was done a decade ago on a linux box, so the L&F is rather motif-ish, but it shows the general concept:
(source: clearlight.com)
It works pretty much as you expect. You can change "ANY of the following" to be "ALL of the following" and the labels on the subsequent lines will change from "or" to "and". The "IS" button can be changed to "IS NOT" as well as "Matches pattern" and a few other choices.
You click on the +/- buttons to add additional criteria. You can create logical groups which allow you to do expressions like "a or (b and c)", yet it still almost reads like a collection of English sentences.
In your case, instead of an "Order by" section you might have a "do these things" section.
This would be cumbersome to use if you have to create very complex queries, but if you're needing a complex query you're probably smart enough not to need a GUI like this. This was designed more for the casual user for simple ad hoc queries.
I would definitely change the way this looks if I had it to do over again, but the basic mechanics work pretty well.
Will it always be binary logic like this (just Or's, And's, and Not's)? If so you could have the UI be a logic diagram designer, similar to the ones used in designing circuit logic.
This is a good article
http://www.lukew.com/ff/entry.asp?1007
I used the ideas in that article when building a form for entering Benefit Deduction rates. The short of it is, that he recommends building the form kinda like Mad Libs (remember those books as a kid).
Okay, I have reached a sort of an impasse.
In my open source project, a .NET-based Oracle database browser, I've implemented a bunch of refactoring tools. So far, so good. The one feature I was really hoping to implement was a big "Global Reformat" that would make the code (scripts, functions, procedures, packages, views, etc.) standards compliant. (I've always been saddened by the lack of decent SQL refactoring tools, and wanted to do something about it.)
Unfortunatey, I am discovering, much to my chagrin, that there doesn't seem to be any one widely-used or even "generally accepted" standard for PL-SQL. That kind of puts a crimp on my implementation plans.
My search has been fairly exhaustive. I've found lots of conflicting documents, threads and articles and the opinions are fairly diverse. (Comma placement, of all things, seems to generate quite a bit of debate.)
So I'm faced with a couple of options:
Add a feature that lets the user customize the standard and then reformat the code according to that standard.
—OR—
Add a feature that lets the user customize the standard and simply generate a violations list like StyleCop does, leaving the SQL untouched.
In my mind, the first option saves the end-users a lot of work, but runs the risk of modifying SQL in potentially unwanted ways. The second option runs the risk of generating lots of warnings and doing no work whatsoever. (It'd just be generally annoying.)
In either scenario, I still have no standard to go by. What I'd need to know from you guys is kind of poll-ish, but kind of not. If you were going to use a tool of this nature, what parts of your SQL code would you want it to warn you about or fix?
Again, I'm just at a loss due to a lack of a cohesive standard. And given that there isn't anything out there that's officially published by Oracle, I think this is something the community could weigh in on. Also, given the way that voting works on SO, the votes would help to establish the popularity of a given "refactoring."
P.S. The engine parses SQL into an expression tree so it can robustly analyze the SQL and reformat it. There should be quite a bit that we can do to correct the format of the SQL. But I am thinking that for the first release of the thing, layout is the primary concern. Though it is worth noting that the thing already has refactorings for converting keywords to upper case, and identifiers to lower case.
PL/SQL is an Ada derivative, however Ada's style guide is almost as gut-twisting disgusting as the one most "old-school" DB-people prefer. (The one where you have to think their caps lock got stuck pretty bad)
Stick with what you already know from .Net, which means sensible identifiers, without encrypting/compressing half the database into 30 chars.
You could use a dictionary and split camel-cased or underscored identifier parts and check if they are real words. Kinda like what FxCop does.
Could be bit annoying, though. Since the average Oracle database has the most atrocious and inconsistent naming guidelines that were obsolete even 30 years ago.
So, I don't think you'll reach the goal of getting clean identifiers everywhere in your projects (or your user's)
Since PL/SQL is case insensitive and columns are preferred over equally named local vars, you'll have to make even more tradeoffs. You can take parts of the style guide of other pascal derivatives (Ada is based on Modula, which is based on Pascal), like Delphi which feel a bit closer to home for PL/SQL (I use a mixture of .Net & Delphi).
Especially the "aPrefix" for parameters can be a life saver, because you won't collide with column names that way:
subtype TName is SomeTable.Name%type;
subtype TId is SomeTable.Id%type;
function Test(aName in TName) return TId is
result TId;
begin
SELECT t.Id
INTO result
FROM SomeTable t
WHERE t.Name = aName;
return result;
exception
when No_Data_Found then
return null;
end;
Without the prefix, oracle would always pick the column "Name" and not the parameter "Name". (Which is pretty annoying, since columns can be qualified with an alias...)
I configured my PL/SQL Devloper to make all keywords in lowercase, however, I made the ones that are used in plain SQL to be uppercased (SELECT,WHERE, etc)
As a result, SQLs are sticking out of the code, but not all my code has to be brutalized by all-upper keywords. (They are highlighted anyways, so what's with the all-upper fetish? ;-) )
When your tool is capable of identifying plain SQLs and give some visual clue, then even the SQL keywords wouldn't need to have a different casing.
btw, I'd love to take a look at it. Can you post an url, or is still "under cover"?
Cheers,
Robert
TOAD has a "pretty printer" and uses a ton of options to give the user some say in what is done. (But it has gotten so complicated that I still can't manage to get the results I would like.)
For me, some options look downward horrible, but it seems that some people like them. A sensible default should be okay for 80% of the time, but as this is an issue of religious wars, I'm sure that you can spend a totally unreasonable amount of time for pretty small results. I'd suggest to code some things to handle the 10-year-old sp you mentioned, and to include something like a <pre> tag that the pretty printer leaves alone.
I like the "standard" Of Tom Kyte (in his books). That means everything in lowercase. Most easy for the eyes.
If all you're doing is rearranging whitespace to make the code look consistently clean, then there's no risk of changing SQL results.
However, as an Oracle/PLSQL developer for the past 8 years, I can almost guarantee I wouldn't use your tool no matter how many options you give it. Bulk reformatting of code sounds great in principle, but then you've totally destroyed its diffability in version control between revisions prior to and after the reformat.
I've been reading this paper: Enforcing Strict Model-View Separation in Template Engines (PDF).
It contends that you only need four constructs within the views:
attribute reference
conditional template inclusion based upon presence/absence of an attribute
recursive template references
template application to a multi-valued attribute similar to lambda functions
and LISP’s map operator
No other logic is allowed within the view - for example if (attr < 5) would not be allowed, only if (valueLessThanFive)
Is this reasonable? Most MVC frameworks allow any logic within the views, which can lead to business logic creeping into the view. But is it really possible to get by with only those four constructs?
For "zebra striped" tables, the paper suggests mapping a list of templates onto the list of data - for example:
map(myList, [oddRowTemplate, evenRowTemplate])
But what if you want to make the first and last rows different styles? What if the 3rd row should be purple on Tuesdays because your graphic designer is mad? These are view-specific (for example if I was outputting the same data as XML I wouldn't use them) so don't seem to belong in the model or controller.
In summary:
Do you need logic above the four constructs listed above within views?
If so, how do you restrict business logic creeping in?
If not, how would you make the 3rd row purple on Tuesdays?
Terence Parr is a very smart guy and his paper has much to commend it, but from a practical point of view I have found using just these constructs somewhat limiting.
It is difficult to prevent business logic creeping in especially if you have the ability to do anything, as for example ASP.NET and JSP would give you. It boils down to how you spend your time:
Allow limited additional functionality (I'm not an advocate for "anything goes") and use code review mechanisms to ensure correct usage, or
Restrict to the four constructs above, and spend more time providing attributes like valueLessThanFive (remembering to rename it to valueLessThanSix when the business requirement changes, or adding valueMoreThanThree - it's a bit facetious as an example but I think you'll know what I'm getting at).
In practice, I find that allowing conditionals and looping constructs is beneficial, as is allowing property traversal such as attr[index].value in template expressions. That allows presentational logic to be effectively managed, while incurring only a small risk of misuse.
Allowing more functionality such as arbitrary method calls gets progressively more "dangerous" (in terms of facilitating misuse). It comes down, to some extent, to the development culture in place in your environment, the development processes, and the level of skill and experience in your team.
Another factor is whether, in your environment, you have the luxury of enforcing strict separation of work between presentation and logic, in terms of having dedicated non-programmer designers who would be fazed by advanced constructs in the template. In that event, you would likely be better off with the more restricted template functionality.
To answer your question about the 3rd row purple on Tuesdays:
The original (or one of the very early) MVC patterns had the 'View' being a data-view, there was no concept of a UI in the pattern. Modern versions of the MVC pattern have felt the need for this data-view which is why we have things like MVVM, MVP, even MV-poo. Once you can create a 'view' of your data that's specific to the UI View it's easier to solve lots of the concerns.
In our case our 'model' is going to get extra properties on it, such as Style or Colour (style is better as it still lets the view define how that style is represented). The controller will take raw 'model' items and present to the view custom 'model' items with this extra Style, giving the 3rd row on Tuesdays a style of 'MadDesignerSpecial', which the view uses to apply the purple colour.
I'm working on a project which will do some complicated analyzing on some user-supplied input. There will be 3 parts of the code:
1) Input supplied by user, such as keywords
2) Rules, such as if keyword 1 is repeated 3 times in keyword 5, do this, etc.
3) And the analyzing itself which executes the rules and processes the user input, and generates the output necessary based on the processing.
Naturally this will lead to a lot of spaghetti code and many, many if statements in the processing code. I want to avoid that, and keep the rules (i.e. the if statements) separately from the code which loops through the user input and generates the output.
How can I do that, i.e. what is the best way?
If you have enough rules that you want to externalize, you could try using a business rules engines, like Drools in Java.
A business rules engine is a software system that executes one or more business rules in a runtime production environment. The rules might come from legal regulation ("An employee can be fired for any reason or no reason but not for an illegal reason"), company policy ("All customers that spend more than $100 at one time will receive a 10% discount"), or other sources. (Wikipedia)
It could be a little bit overhead depending of what you're trying to do. In my company we're using such kind of tools for our quality analysis tool.
Store it in XML. Easy to parse and update.
I had designed a code generator, which can be controllable from a xml file.
For each command I had a entry in the xml. I was processing the node to generate the opcode for that command. Node itself contains the actions I need to do for getting the opcode. For some commands I had to look into database, all those things I had put in this xml file.
Well, i doubt that it is necessary to have hughe if statements if polymorphism is applied correctly.
Actually, you need a proper domain model for your rules. This goes somehow into the direction of the command pattern, depending on the complexitiy of your code maybe in combination with the state machine pattern.
Once you have your model, defining rules is instantiate them correctly.
This could be done by having an xml definition, which is parsed and transformed into your model. But the new modern and even more fancy way would be using DSLs. If you program in Java and have a certain freedom about your libraries, this would be a proper use case for Embedded DSLs with Groovy. Basically you would need a Builder which constructs your model, that's all.
You always can implement factory that will create certain strategies according to passed parameters. And then you will use those strategies in your code without any if.
If it's just detecting keywords, a finite state machine or similar. If it's doing more, then other pattern matching systems, such as rules engines.
Adding an embedded scripting language to your application might help. The rules would then be expressed in scripts, executed by the applications on processing.
The idea is that scripts are easy to change and contain high level logic that will be executed by your application in details.
There are a lot of scripting languages available to do this : lua, Python, Falcon, squirrel, angelscript, etc.
Have a look at rule engines!
The approach from Lars may also be arguable.