The next step is to transform the diagram into your Corticon Vocabulary. This can be done in Corticon Studio using its built-in Vocabulary Editor.

In Corticon Studio, choose New > Rule Project. Click the Rule Project, and then choose New > Vocabulary. Create the entities, attributes, and associations that were defined in the diagram.

Note: See Vocabulary topics for complete details on building a Vocabulary.

The naming conventions for the entities and attributes will be used in the Vocabulary:

  • All attributes in our Vocabulary must have a data type specified. These data types can be any of the following common data types: String, Boolean, DateTime, Date, Time, Integer, or Decimal.
  • Attributes are classified according to the method by which their values are assigned. They are either:
    • Base: Values are obtained directly from input data or request message
    • Transient: Created, derived, or assigned by rules in Studio.
      Note:

      Transient attributes carry or hold values while rules are executing within a single Rulesheet. Because XML messages returned by a Decision Service do not contain transient attributes, these attributes and their values cannot be used by external components or applications. If an attribute value is used by an external application or component, then the attribute must be a base attribute.

      To show the rule modeler which attributes are base and which are transient, Corticon Studio adds an orange bar to transient attributes, as shown for packDate:

      XML response messages created by Corticon Server will not contain the packDate attribute.

      It is a good idea to use a naming convention that distinguishes transient attributes from base attributes. For example, you could start a transient attribute's name with t_ such as t_packDate. Do not use names that are cryptic. The intent is to express the names in terms that are understood by business users as well as developers.
  • Associations between entities have role names that are assigned when you build the associations in the UML class diagram or Vocabulary Editor. Default role names simply duplicate the entity name, with the first letter in lowercase. For example, the association between the Cargo and FlightPlan entities would have a role name of flightPlan as seen by the Cargo entity, and cargo as seen by the FlightPlan entity. Roles are useful in clarifying context in a rule. A topic that covers this in more detail in the Scope chapter.
  • Associations between entities can be directional (one way) or bidirectional (two way). If the association between FlightPlan and Aircraft were directional (with FlightPlan as the source entity and Aircraft as the target), you would only be able to write rules that traverse from FlightPlan to Aircraft, but not the other way. This means that a rule can use the Vocabulary term flightPlan.aircraft.tailNumber but cannot use aircraft.flightPlan.flightNumber. Bidirectional associations allow you to traverse the association in either direction, which allows you more flexibility in writing rules. Therefore, Progress strongly recommends that all associations be bidirectional whenever possible. New associations are bidirectional by default.
  • Associations also have cardinality, which indicates how many instances of a given entity can be associated with another entity. For example, in the air cargo scenario, each instance of FlightPlan will be associated with only one instance of Aircraft, so there is a one-to-one relationship between FlightPlan and Aircraft. The practice of specifying cardinality in the Vocabulary deviates from the UML class modeling technique because assigning cardinality can be viewed as defining a constraint-type rule. For example, a flightPlan schedules exactly one aircraft and one cargo shipment is a constraint-type business rule that can be implemented in a Corticon Studio as well as embedded in the associations within a Vocabulary. In practice, however, it may often be more convenient to embed these constraints in the Vocabulary, especially if they are unlikely to change.
  • Another consideration when creating a Vocabulary is whether derived attributes must be saved (or persisted) external to Corticon Studio, for example, in a database. It is important to note that while the structure of your Vocabulary may closely match your data model (often persisted in a relational database), the Vocabulary is not required to include all of the database entities/tables or attributes/columns, especially if they will not be used for writing rules. Conversely, the Vocabulary may contain attributes that are used only as transient variables in rules and that do not correspond to fields in an external database.
  • Finally, the Vocabulary must contain all of the entities and attributes needed to build rules in Corticon Studio that reproduce the decision points of the business process being automated. This process will most likely be iterative, with multiple Vocabulary changes being made as the rules are built, refined, and tested. It is common to discover, while building rules, that the Vocabulary does not contain all the necessary terms. But, the flexibility of Corticon Studio permits the rule developer to update or modify the Vocabulary immediately, without programming.
The following figure shows the vocabulary modeled in Corticon Studio:
Figure 1. Vocabulary Window in Corticon Studio