BA Concept - Declarative Knowledge

6/20/99 - Go Back

The basic reuse mechanism is DK.

As the software industry matures, we keep finding better reuse mechanisms. There has been somewhat of a progression from copying and pasting code, methods, subclassing and table driven. The BA goes one step futher and uses Declarative Knowledge (DK) to declare what to do, and the reusable element (part or container) figures out how to do it. This is a quantum leap, and is the biggest productivity feature of the BA. As you will see, DK allows reuse to be approached in an entirely new way. It is much like XML.

In the BA, DK is stored in text files with a "parex" extension, short for "parameter text". These are designed to be very human readable and editable, making things easier. DK files can be named anything. The default is to name part files "PartName.parex" and container files "_Container.parex".

Practice - (to be continued ***)

Part DK is used by a part to initialize itself. (ParamDriven interface)

This is the simpler type of DK, and is the one discussed in the glossary entry for Declarative Knowledge. Here's another partial example for a visual part to edit DK:

Window has:
    Title is: DK Editor
    Width is: 400
    Height is: 500
    Position is: UpperRight
    End: Window
EditorPane is: org.jcon.baedit.dk.TreeEditorXML
Validator is: org.jcon.baedit.dk.ValidatorDTD

Note how using this DK we can configure the "policies" used, such as which editor and which validator.

Parameter driven parts must implement the org.jcon.param.ParamDriven interface. The methods and short documentation are:

public interface ParamDriven {
    // Sets the part's DK. The part can use the DK
    // any way it wants, such as initialization and rules.
    // This is called when the part is created.
    public void setParam(Param param);
    // The part should apply the new Param any way it wants.
    public boolean applyNewParam(Param newParam);
    // For future use. Return null for now.
    public ParamDrivenInfo getParamDrivenInfo();
}

Practice - (to be continued ***)

Container DK is used to define a container's parts and relationships.

This is more formidable. The goal of Container DK is to populate a container with parts, set their relationships, and then start, close, etc the container when needed. Here's an actual example from org.jcon.ba.tree._Container.parex. Note - These days we are starting part names with a capital, such as TreeMgr.

// _Container.parex - The tree module
this_Item has:
    IsContainer is: true
    Config hasLines:
        addMessageListener("TreeOpened", ML treeMgr)
        addMessageListener("CloseAllTrees", ML treeMgr)
        addMessageListener("ParamApplied", ML treeMgr)
        End: Config
    End: this_Item
//========== ItemDefs ==============================
eventRouter_Item has:
    BeanClassName is: org.jcon.ba.system.router.EventRouterBIP
    Config hasLines:
        provideListener("org.jcon.ba.tree.ItemTreeListenerProxy", Object treeMgr)
        End: Config
    End: eventRouter_Item
treeMgr_Item has:
    BeanClassName is: org.jcon.ba.tree.TreeMgr
    Config hasLines:
        addMessageListener("EditParam", ML this)
        addMessageListener("GroupClosed", ML this)
        addMessageListener("EditModule", ML this)
        addMessageListener("InspectItem", ML this)
        addMessageListener("ItemSelected", ML this)
        End: Config
    End: treeMgr_Item
//========== Primordial ============================
PrimordialInvocations hasLines:
    End: PrimordialInvocations

Pardon the long example, but it's nice to see the real thing. It has three sections.

1.Container configuration - The first section is used to configure "this" container. As you can see, we add a listener (the part named treeMgr) to the container for three different Messages.

2. Item Definitions - In the ItemDefs section, we list the parts and the configuration for each part. This defines all the parts in the conatiner. Note a part can be a container or leaf.

3. Primordial Invocations - In the last section, we define methods on parts that are invoked when the container was started. "Primordial" means "pertaining to or existing at the very beginning".

In this example there are no primordial invocations. There are always some in the root container. Otherwise when a system was started no parts would start working!!! For example in a root container we might see the invocation "MainMenu.start()", which would cause the GUI to appear.

Practice - (to be continued ***)