KBM Conceptual Classes
Posted on 25 Jul 2020; 07:00 PM IST. Last Updated 27 Jul 2020; 01:00 AM IST.Summary: KBM Conceptual classes depict knowledge in an abstract form, without specificities of the underlying implementation scheme, and allow developers to elevate atomic data types such as int, float to higher level types. KBM conceptual classes and colors need not be coded along with the class, but can be applied later as an adornment, and are stored separately, without disturbing the original definition of the oops class. KBM Conceptual Classes are explained below with the aid of examples.
KBM Conceptual classes depict knowledge in an abstract form, without specificities of the underlying implementation scheme.
In oops, an attribute of an object is defined in the class definition, using the following paradigm.
datatype fieldname;
For example, in a Sales Order Item class definition, we could often find an attribute (or field) like quantity ordered, defined as:
int qtyOrdered;
The data type “int” is a storage specification, which crept into higher level languages, all the way from assembly language.
We could prefix the above description with a conceptual type as shown below.
class SalesOrderItem {
- - -
$Part int qtyOrdered;
- - -
}
We regard SalesOrderItem.%v-def as an instance of the SalesOrderItem class, although the instantiation is not shown here.
The prefix $Part for the field qtyOrdered is called a Conceptual Class, and this would allow us to represent the field as: $Part.qtyOrdered;
The same conceptual class could appear as prefix of many fields. The conceptual class may have sub divisions, which are represented as sub tags which begin with a “$”. A conceptual class with subdivisions is called a Conceptual Sub Class. We are more likely to see a conceptual sub class as a prefix than a conceptual class, hence by default these prefixes are generally regarded as conceptual sub classes.
In KBM, colors (or concepts) may also be applied to fields. Thus, the field name “qtyOrdered” may be represented as:
qty.%v-Ordered;
In view of the conceptual class, the field definition may now be viewed as:
$Part.qty.%v-Ordered;
The definition shown above is highly abstract, and is devoid of implementation specifications.
The conceptual classes and colors need not be coded along with the class, but can be applied later as an adornment, and are stored separately, without disturbing the original definition of the oops class.
The conceptual class (or sub class) “$Part” may exist in multiple class definitions. For example, we could have an Invoice Item class, and an attribute definition given as:
class InvoiceItem {
- - -
$Part int qtyInvoiced;
- - -
}
We regard InvoiceItem.%v-def as an instance of the InvoiceItem class, although the instantiation is not shown here.
In view of the conceptual class, the field definition may now be viewed as:
$Part.qty.%v-Invoiced;
A conceptual Class (or sub class) such as “$Part” could exist several times in the same concrete class and/or could exist in several concrete class definitions.
Just by looking at $Part, we could no longer tell, if the attribute were to come from Sales Order Item or Invoice Item concrete object. We could resolve the conflict by adding an auxiliary verb color to the Conceptual class “$Part”.
The auxiliary verb provides a mapping such as:
$Part.%a-soitem -> SalesOrderItem.%v-def;
$Part.%a-invitem -> InvoiceItem.%v-def;
We could now access the fields as shown below.
$Part.%a-soitem.qty.%v-ordered;
which gets translated as: SalesOrderItem.%v-def.qty.%v-ordered;
where, SalesOrderItem.%v-def is an instance of SalesOrderItem.
$Part.%a-invitem.qty.%v-invoiced;
which gets translated as: InvoiceItem.%v-def.qty.%v-invoiced;
where, InvoiceItem.%v-def is an instance of InvoiceItem.
Conclusion
Conceptual sub classes allow us to elevate atomic data types such as int, float to higher level types. Since the same conceptual type may be assigned to fields in different objects (oops classes), we could recognize the underlying commonality of these fields.
The concrete object need not directly code colors, conceptual sub classes. These adornments are stored separately, and are processed separately.
Another big advantage we could reap is that we could access the fields of the concrete object, using a different standard directly, without the need for an adapter or facade pattern (please refer to annexure-1).
Annexure- 1
Object Oriented Programming paradigm (or oops) is an implementation scheme, which is strongly bound to specificities like class names, and package names (or name spaces). To access an attribute of an object, we need an instance of an object, which in turn requires specification of a package name, and class name.
One of the biggest problems of oops paradigm is it cannot be easily lifted to a higher conceptual level. This problem is described below in greater detail, with the aid of an example.
Assume that there is a standard scheme to refer to a Sales Order object, given by a standards body, which we regard as conceptualization of Sales Order.
A particular organization may have a very specific implementation of the Sales Order object called concrete object. We could in theory map all or many attributes of the concrete implementation to the conceptualized version given by the standards body.
We could employ the adapter design pattern and access the Sales Order object due to concrete implementation using the specification given by the standards body. The adapter makes the concrete object appear like the standard or conceptualized object.
The above technique allows us to achieve conceptualization. But the underlying problem is we need to create an adapter. If we have two different specific (or concrete) implementations, we need two adapters.
Adapters typically cache an instance of the concrete object, and forward the request from the caller to the object and return the response back.
This technique has the following overheads:
a) Access overhead: A caller interacts with the adapter using the standard or conceptualized representation, and this call is forwarded to the cached concrete object, and the response is sent back.
b) Storage overhead: Every concrete object needs an adapter object in storage, at runtime.
c) Maintenance Overhead: Whenever the concrete object is revised, the adapter must be upgraded and retested.
References:
1. Mechanism and System for Representing and Processing Rules; USPTO. Patent Number: 7,890,928. Date: Feb 15, 2011.
2. Mechanism and System for Representing and Processing Activity Models; USPTO. Patent Number: 9,176,951; Nov 03, 2015.