Dulcian's BRIM^® FAQ

ID#

Question

Answer

1

How can you deal with the "temporal scope of a rule" in BRIM^®?

What happens when you edit the object? What is the valid date?

 We have chosen not to implement it because we have a hard enough time getting designers to put the little crows feet on the right side of the lines. This would add a whole new dimension to every rule in the repository.

It is not a good idea to include that level of complexity in the system.  It is currently supported by versioning the whole rule.  However, we did not want to look at the date on each object and enforce a different set of rules based on the object date. 

In our keyword {history} that we place on objects, we enforce that you can't have a future start date or end date.  There is no way to deal with the problems that arise from future potential rule violations. 

Therefore it is a solvable problem.  We worked out the whole algorithm about 2 years ago.  But there are 2 outstanding issues:

1) It is unclear whether or not you can get good performance out of the system when this functionality is included.  It makes for very complex queries for every record you Insert, Modify or Delete.

2) It is difficult for most designers to understand the complexity of the temporal scope of rules.

2

If I can get all of the logic out of the application, why isn't it better to do the final layout using a layout editor?

I thought I would use BRIM^® but it does not support any "front end" design and generation.

We thought that a generic application that does the same thing as generated applications would be a better approach.  Then, custom user interfaces can be built by hand where necessary.

But, you are right.  The best way to build a pretty UI is with a real UI development tool and not a generator. 

3

If your generic form can modify itself at runtime, I would imagine that in that case you need to store some control info in your BRIM^® repository to tell your generic form how to modify itself to meet the user expectations... And that sounds like UI "generation"

Almost.  The overall driving "theory" is cost minimization.

"The goal of system development is to build a good system while minimizing the development and maintenance costs of the project over its lifetime."

But the idea is that it is about the inputs (money) and the outputs (a quality system).  Everything else is just the vehicle. It is not an absolute necessity that all of the rules must be placed in the repository.  There are some rules that are most easily supported by writing code.  Some batch routines are most easily handled by a good programmer sitting down for a few weeks and writing a big routine.  And some forms are best built by an Oracle Forms developer writing them. There are benefits to 100% generation just as there are benefits to a complete rule repository, but not if we pay more for it than the benefit. 

In earlier versions of the repository, attributes of  x, y, height, width were included.  But Forms does not do well with creating objects on the fly. Instead we use a multi record block (col 1 = attribute name, column 2 = attribute value) for single record display that uses attribute order. When we convert the Object Builder to Java and have the ability to do anything at runtime, we will add more to the design time parameters.

It was never clear why Designer didn't add enough to the repository so that design capture was 100% complete.  That way we could have generated and modified the form without breaking the link to Designer. In the article for the ODTUG Journal "The Case against Designer Generation" (See Publications/Magazine Articles/ODTUG Journal), this was one of the main reasons cited for abandoning Forms generation.

It is still not clear that fancy layout isn't handled better in a tool that designed for that purpose.  JDeveloper is a new product, and it does not appear to be going in the same direction as Designer for UI creation. 

4

If you do not store UI layout info in the BRIM^® or somewhere else, then how does your generic form know how to modify itself at runtime?

Some of the UI information comes from the data model. Some is in domains,

column order, etc.

It is probably about as far as non-expert Designer shops go in generation.

Certainly a really good Designer shop can generate a better UI.  (They will spend a lot more time doing it, but you can get better results.)

This all started with the idea of extending the Designer ERD to provide enough information to generate the applications without a module diagrammer. So we extended UML class diagrams to support data modeling.

 In a UML class diagram it is clear what are an object's components (composition children) so they can be shown as child objects in the Navigator. Display functions and driving the UI with diagrams, all help.

A generic form has some advantages over a single focus form.  You can see all the objects of the system in one place and can navigate from object to object much more easily. Although you can make Forms do this, it is certainly more natural to do it in a generic form.

We added an object editing history so that you can quickly move back to an object you previously edited.  We added this functionality based on an issue that came up in a customer tracking system that we built. For example, if you create an email object and it returned an error because the person you wanted to send an email to didn't have an email address, you can navigate to the person object to add the email address and then get back to the email object without having to look for it. Therefore, the system includes forward, back, and "goto a specific object" capability.

Dynamically, we can control:

1) What classes you can edit, add to, delete from,...

2) What attributes you can see or edit

3) Attribute order

4) The display function for the object to show the right information for an object

5) What child records are visible

6) How an attribute is edited (pop list, edit box, calendar widget)

7) All processing on the object through the state engine

We don't dynamically position fields on the screen other than order.  Their color is changed based on whether or not they can be edited.

You can get to a record by double-clicking it.  For example, in EMP, if you double click on the department name, you change focus to that department. Then in DEPT, you could click on the Back button to get back to the EMP. Or, you would see the emps as child records so if you double clicked on a particular EMP, you would get back to that EMP.

For the folks that start using BRIM™, we would be interested in knowing where you think the Object Builder should go next.  Our preference would be to develop a better object finder. We have a really good object editor, but finding a particular object in a class with 10,000,000 records would be hard if you didn't know much about it. For those of you familiar with the Oracle Developer: Advanced Forms & Reports book (Dorsey & Koletzke, Oracle Press, 1999) the goal is to build a generic version of the locator tab in a Forms application.

5

Can you give me your definition of a business rule?

Some people claim it's a yes/no answer to a question - obviously your definition differs.

---You are right that everyone will give you a different answer to this question.

Most people in the Business Rules community think of a rules as statements about how the business works.  Notice particularly how this definition is different from a system requirement, although there is lots of overlap.  Many things that are requirements are rules and vice versa.

David Wendelken's partitioning is as follows:

1) "To rule", as in "to govern".  A rule by this meaning constrains the way in which the business operates.

2) "Rule", as in "ruler", "to measure".  A rule by this meaning defines how some aspect of the business is measured.

This division is a reasonable one, though not the only one. Most designers have their own way of partitioning the rules.  The "correct" partitioning may depend upon many factors (the project, the team, the scope ...). The goal is to gather statements about the business and then manage them.  Using partitioning helps to organize the rules and make sure that as few as possible are omitted. 

We start with a partitioning of analysis rules verses implementation rules. Analysis rules are the traditional business statements.  The implementation rules are representations of the rules of the systems that can be implemented directly. Using our approach,  analysis rules cannot also serve as implementation rules.

Analysis rules need to be stated in the same way that people think and talk.  People's thinking and talking is usually not rigorous enough to implement and formal representations are different from how people think and talk. It may not be impossible, but I have yet to see a single mechanism that supports both.

For analysis rules, the correct partitioning is unclear. In BRIM™ we are building a structure where you build your own partitioning as a BRIM™ project and then attach the rules to BRIM™ implementation rules at the class or state level.  At this point, we do not believe that there is a universal rule structure for analysis.

For implementation rules, we use extended UML class and activity diagrams.

6

Is BRIM^® a take-off on CASE methodology?

To some extent you are right.  A fair way to characterize BRIM™ is as next generation CASE.  There are a few key differences between BRIM and a traditional CASE tool.  In comparing BRIM™ to Oracle's Designer:

1) BRIM™ supports a much higher percentage of the business rules (system specifications) than Designer.  In Designer projects, usually only about half of what the system needs to do can be nicely handled in the repository. The rest has to be hand coded or handled through generic data models. In BRIM™, we have the hand coding down to perhaps 3-5%.

2) Designer is really focused on system specifications, BRIM™ is focused on business rules.  In the actual implementation philosophies, they look pretty similar, but at the edges, you see a lot of differences.  Everything in BRIM™ is about describing objects and their behavior (rules).  The physical implementation of those "rules" is in a separate part of the tool.  In Designer, it is clear that you are designing a database and building applications.

3) Rather than generate applications, we generate at a slightly higher level of abstraction.  BRIM™ generates the object specifications and their behaviors.  The implication is that the object logic belongs to the object, not the application.  Any application that manipulates the object will be controlled by the same rules.  We do have an equivalent to generated applications.  We have a single "smart" application that can run an entire database.  The quality of the user interface is about the same as Designer generated applications.

7

Have you seen BRIM^® really work for complex applications?

The product is quite mature now.  We delivered our first implementation a few years ago.  It runs a county tax collection bureau. It is a quite complex setup.  Some of the process flows have hundreds of states.

We have validated that we experience no performance degradation for up to 50,000,000 records in the database (we ran out of disk space at that point). The idea is that BRIM™ generates simple Oracle tables, views and PL/SQL code. This ensures scalability.

8

How does BRIMä deal with ETL rules?

---------------

---------------------------------

Gabriel Tanase asked:

Can't you deal with the issue in the following way?

Step 1: The set of ETL source objects maps to a single super-object in BRIM^®.

Rephrasing: this super-object "interacts" with this set of ETL source objects as per such and such "source rules".

Step 2: The super-object maps to a set of objects in ETL target.

Rephrasing: this super-object interacts with this set of ETL target objects as per such and such "target rules".

I have had a number of requests to make the BRIMä (our rules engine) handle ETL rules.  In particular, on a big project we are doing now, we had to support such rules.

I ended up making a BRIMä project to support the storage of the rules and wrote a new generator to generate the code.

I was bothered by the reasons why I had to do that.  I thought we had made the rules engine robust enough to support most anything. I figured out the problem, and I thought I would share my thoughts with you.

In general, when we think of business rules, we think in the context of an object.  "This is a rule that pertains to the way employees are created." "Purchase orders over $5000 must be approved." Rules may also be associated with the way in which objects interact: "Employees must be assigned to a department."

In ETL, the rules are of a different nature.  In this situation, we are talking about the way groups of objects relate to each other.  "This set of objects maps to this other set of objects."

Even within ETL, there are different kinds of issues.  For our big project, we are building an ETL to support single object mapping.  The user fills out a form and we copy it into the database.  The form may be stored in several tables and the target is also several tables.

-------------------------------------------------------------------

The idea is that for an ETL map you have a read class and one or more write classes.  Reads can be nested (writes don't need to be in our simplified ETL situation).

Most rules environments that are object based (like BRIMä) have the rules associated with the classes.  ETL rules are fundamentally different and therefore cannot be included with the standard rules.

The point  is that rules repositories are not generalized things.  They support some rules easily and some with greater difficulty.  You have to partition rules so that you can use the easiest mechanism for each type of rule.  A generalized rule grammar will be nothing more than another programming language and therefore hold no advantage. ETL rules look very different from any other rule I have ever supported.

The rules are the same for bulk loads, but the generated code is different.

Terry Moriarty asked: Are there any other ways that rules can reused?

I have come up with the following ways to reuse rules.

1) A rule can be enforced by a function that can be called anywhere.

2) Objects that have process flows can be called from within another object's flow (think of it as a subroutine).

3) Within an object, the same state can be reached in lots of ways, so the same logic can be reused. Reusing pieces of process flows for different types of objects does not makes sense since, within a flow, you have to specify the attribute privileges for the object for which the flow is being created. Because each object has different attributes, there is no way to reuse pieces of process flows.

4) You can make generic "rules patterns" that can reused.  For example, I use the idea of a "history" keyword to mean that the class has a startDate, endDate.  The attribute startDate must be less than endDate.

5) You can make special rules structures that are accessed using reusable functions.

Ricardo Patrocinio asked:

Does anyone here use Rational RequisitePro?

I'd like to know your opinion about the product, and pros and cons

between:

- Rational RequisitePro,

- Oracle Designer; and

- Ducian BRIM^®

 I am obviously biased, but I will tell you my perception.

I think we need to start with what you want to do.

The 3 products are very different and are designed for different audiences that do different tasks.

Designer

Designer, at its roots, was designed to support generation of the database and the Oracle development products (originally Forms and Reports).  With the exception of the theoretical work done years ago by R Barker, I think it fair to say that Designer is very much a bottom-up product.  What drove it was trying to give designers a way to nicely represent design structures. 

Designer, very successfully handles traditional database design.  If you want to build a traditional relational database, there is no better tool on the market.  I think it crushes competitors like Erwin in the Oracle environment.

For application generation, there are differing opinions.  Many shops have successfully used (and continue to use) Designer for application generation but many more have failed. I looked into it, used it on a few projects but never saw any benefit to the application generation. But I never built systems in a traditional way. There is a paper on our website that explains this in detail: http://www.dulcian.com/magazine%20articles/The%20Case%20Against%20Designer%20Generation.htm

Pre-BRIM^®, I built using highly generic data models that required only a few dozen applications for even the most complex systems.  This meant that I could manage app development without a repository, and my applicaitons were complex enough that Designer generation was not really practical.

Designer application generation was designed to support generation of applications that look a lot like those in Oracle Financials, namely lots and lots of little applications doing insert, update and delete operations.  The ability to support process is almost non-existent.

The sweet spot for Designer application generation is a large traditional database design with a medium to large team and lots (hundreds) of similar looking applications.

On the down side, Designer has been declared a "mature" (euphemism for "largely abandoned") product. The thinking behind Designer is over a decade old and it shows.  There is no process, no OO, and the product is well out of synch with where I think the next generation is going (but I am sure that current Designer users will respond on this thread and tell you how it is still a wonderful product).

RequisitePro

This product Is part of the Rational suite for handling analysis. To be fair, I will comment on the whole suite not just the RequisitePro piece. RequisitePro is a document management application that helps you manage and build your analysis document. You would also want to get the full Rose UML suite to build your system.

The Rose suite (as most people call it) is a UML-based design and generation environment designed by and for OO software developers. It has strong support for all of the useful parts of UML for doing analysis and design.  It doesn't generate much of the system and I am not at all happy with the database generation. OO people tend to say "The database is just a place to store a persistent copy of our classes." As a result, they often ignore PKs, normalization, or any of the other basics of database design.

They have also thought though integrating good software engineering with the product and created RUP (Rational Unified Process). It does for their suite what Peter Koletzke and I did with Designer in the Designer Handbooks with CADM (Case Application Development Method).

For doing OO analysis and design, there is no better product than Rose. It is very mature and has been around for years.  It is very clean and deep.

My issue with it is that it is designed for OO software developers. In ODTUG, I think we all want to start with a solid RDBMS that the applications sit on top of.  There Rose is quite weak.

BRIM^®

The Business Rule Information Manager (BRIM^®) is my company's tool. BRIM^® works from an entirely different direction than the other tools.  We start with trying to capture the business rules of the system in a repository. Then, in an independent second step, we decide how to generate a system using those logical rules.

So, we solve 2 independent problems:

            1) Articulation of the system in a product-independent way

            2) Generation of that articulation

This is really the fundamental difference in BRIM^®.

BRIM^® is UML-based, but that is more of a marketing aspect. When BRIM^® started out, we were inventing our own rules grammar to support us.  It wasn't until we were a few years into it that we adapted our grammar to UML to be consistent with industry standards. As UML detractors are correct in saying, UML doesn't really support full system articulation. So, we extended UML until it did.

BRIM^® allows designers to draw a UML class diagram and then we generate a database directly from that.  There is no logical versus physical design (this is another way we differ from Designer).  "The rules ARE the system" is one of our mottos.  

We use a significant extension to UML process modeling to support process flows. We then generate almost the entire system from the rules.

We also are the only product generating a usable DB from a UML class diagram, and no one else integrates process into the system generation nearly as well.

As to pros and cons, I am not sure I can objectively describe these. There are lots of white papers on our web site in the BRIM^® area: http://www.dulcian.com/BRIM.htm