Overview of BRIMä Architecture

Dr. Paul Dorsey

Dulcian, Inc.

July 27, 2002

Dulcian’s Business Rules Information Manager (BRIMä) is a complete systems design and development environment. In BRIM’s business rules-based system development environment, all of the business rules for the system are placed into a single repository.

With the Repository Manager user interface, UML class and activity diagrams are used to represent the business rules and enter them into the repository. From the entered rules, BRIM generates a system composed of Oracle tables, views and PL/SQL procedures. Interaction with the generated system is accomplished via a single generic application that can be used to maintain the entire system. The generated portions of the system can also be bolted to any other user interface, if desired. The basic BRIM architecture is shown in Figure 1.

Figure 1: BRIMä Architecture

Rule Representation

Business rules are entered into the system using two applications:

· Domain Builder: Used to specify attribute domains

· Repository Manager: UML class and activity diagram-based modeling tool where the remainder of the system’s rules are represented

Domain Builder

Every attribute in BRIMä is assigned a domain. Domains restrict the valid values for an attribute and can either be simple (date, numeric, character) or value list (reference tables). Domains of all types are maintained using the Domain Builder application. BRIM can support any number of domains.

Attribute domains can be any standard Oracle datatype. The types of domains include value lists, simple and function-based for complex validation. Domains may be inactivated when no longer needed. Figure 2 shows the Domain application with valid domains.

Figure 2: Domain Builder application

Value list domains can either be simple lists of values (LOVs) or recursive (hierarchical).

Individual values can be flagged as active and/or selectable. There is a version of the Domain Builder available to support multi-lingual value list domains.

Attribute values all have codes, display values, optional ordering and descriptions. In the Domain Builder, there are two ways of viewing the values in a value list: tree list or a multi-level master details structure as shown in Figures 3 and 4.

Figure 3: Tree structure value list

Figure 4: Master Detail value list

Repository Manager

The BRIMÔ Repository Manager is the main rule entry environment for BRIMÔ This application is written entirely in Java and used to populate the BRIMÔ repository. Structural rules are entered using UML class diagrams similar to relational ERDs but with greater functionality. Those familiar with entity relationship modeling will have little trouble with the transition to UML. Entities translate to classes, relationships translate to associations, etc. UML also provides many advantages over ERDs. Generalization in UML is a more powerful construct than ERD supertypes/subtypes; Aggregation and Composition are more powerful than ERD dependency relationships (UID bars).

All core UML functionality is supported including generalizations, composition, aggregation and XORs. In addition, BRIMÔ supports a number of extensions to UML that further enhance the richness of the modeling environment. Entry of the UML diagram is accomplished with a user-friendly graphical tool shown in Figure 5.

Figure 5: Data model for a timesheet system shown in BRIMÔ

Process flow information is also maintained using the Repository Manager.

Process Flows in BRIMÔ

Process flows in BRIMÔ are significantly different from those in other process flow tools on the market. Most are based either on flowchart or State Transition Engine (STE) technology. As a result, process flows tend to look straightforward for a demo but can be extraordinarily complex when used in production.

BRIMÔ surmounts this problem by approaching the idea of process flows from a business user’s idea of a “state.” Conceptually, a BRIMÔ state is similar to a manual workstation including a desk with an inbox and an outbox. When a document is placed in a worker’s inbox, some tasks are automatically performed. If the worker does not remove the document within a specified period of time, the document is sent to another workstation. When the worker removes the document from the inbox, another set of tasks were automatically performed. Others require individual judgments. When finished with the document, decisions about where it should be routed next are made before moving it to the outbox. This idea of a BRIMÔ state is quite rich. On average, one BRIMÔ state will replace some 20-30 STE states. A complex BRIMÔ state may involve as many as 50 STE states.

A BRIMÔ process flow is shown in Figure 6. Although not unreasonable complex, this diagram represents the processing for a single BRIMÔ state.

Figure 6: BRIMÔ “Inbox” state

Figure 7 shows a BRIMÔ process flow. If each state in this relatively simple process flow were replaced with 30 or more states, the diagram would become unreadable.

Figure 7: BRIMÔ Process Flow

BRIM™ Repository

The BRIMÔ Repository is a set of Oracle tables. Population of the repository need not be done exclusively through the Repository Manager. A complete set of APIs exists (some used by the Repository Manager), any or all of which can be used to manipulate the repository.

The data model for the repository is easily understood with classes stored in the UML_Class table, etc. This fully documented data model is delivered as its own application with the full BRIMÔ product. Similarly, all APIs for interacting with the repository are well documented and available for use.

A set of repository reports are also delivered with BRIMÔ, built using Oracle Reports. However, since the repository is stored in simple Oracle tables, BRIMÔ users can easily write their own reports using any reporting tool.

BRIMÔ-Generated Systems

Once the business rules have been placed in the BRIMÔ repository, the system can be generated. This is one of the real strengths of the BRIMÔ environment. You do not have to wait for the system to be complete before generating a first version. BRIMÔ developers should get into the habit of generating a system as soon as there is enough of the system entered to test. Additional system pieces can be quickly generated, supporting a RAD environment with virtually no cycle time.

BRIMÔ generated systems are built using basic Oracle structures and can support very complex rule enforcement. Structural business rules entered into the UML Data Modeler generate simple tables and views with INSTEAD-OF triggers. This creates what looks like a normal relational database. From a developer’s perspective, everything that is possible in a standard relational database is also possible in a BRIMÔ environment. However, there are significant advantages to using BRIMÔ.

Because of how generalization (supertypes/subtypes in ERDs) is implemented in a BRIMÔ environment, developers can interact with different levels of data abstraction in the system. When building an Employee application, the BRIMÔ developer could instead or in addition choose to build an application based on a Party structure, treating the data model as one construct by using generic modeling techniques. This gives developers unparalleled flexibility.

Process flow information is generated as simple PL/SQL stored procedures. These procedures govern the movement of objects in classes from state to state. The BRIMÔ engine architecture fully enforces object locking to enable this technology. For example, state-dependent objects must be opened before they can be edited. Only one person may open an object at any given time.

Interacting with a BRIMÔ-Developed System

No application development is necessary when working in a BRIMÔ environment due to the presence of its Object Builder. The BRIMÔ Object Builder is an Oracle Forms application that can be run client/server or over the web. It can be used to locate, insert, update or delete any object in the database. The Object Builder can be customized to grant visibility only to selected classes and is user-friendly enough to require very little training. Anyone familiar with a standard Windows environment will find the same types of menus, toolbars, pulldowns and other functionality that they are used to.

The BRIMÔ Object Builder takes advantage of all rules stored in the BRIMÔ repository. For example, value list attributes are manipulated using pulldowns. Date attributes are manipulated with a calendar object.

Process flows are integrated into the Object Builder so that they can be opened and processed directly. A sample Object Builder screen is shown in Figure 8.

Figure 8: BRIMÔ Object Builder

The Object Builder replaces generated applications. A single flexible application strategy was selected over using several generated applications for the following reasons:

1. Manageability: Changes to the business rules do not require regeneration or redevelopment.

2. Navigation: Moving from object to object is simpler, not requiring changing applications. Applications can keep an object’s editing history and easily go back to a previously edited object.

3. User Friendliness and Sophistication: Applications can still be custom-built rather than generated.

For the parts of the application requiring a very high-quality user interface, developers will want to build a few carefully designed applications to support frequently used portions of the system. However, such applications will be much easier to build in a BRIMÔ environment than they would be in a traditional development environment for several reasons:

1. As mentioned earlier, applications can be written at any level of abstraction, allowing developers to choose either a number of smaller applications or one larger but more flexible application.

2. The BRIMÔ Repository and its associated procedures and functions greatly decreases the amount of work required to build an application. Developers can simply create an Object Viewer application.

In BRIMÔ, all of the complex business logic is stored in the repository which then generates the appropriate structures. Developers can take advantage of these structures to build applications very quickly. An added advantage is that most business rule changes do not require any modifications to the existing applications.