Formalizing Knowledge

Knowledge formalization comprises four activities:

• Gathering requirements relevant to the domain of interest

• Abstracting that knowledge into some set of concepts

• Expressing those concepts formally in a model

• Testing the model for correctness (preferably by executing it)

Gathering Requirements

Every subject matter area has a set of requirements placed upon it by its owners and users. A banking system, for example, may make loans, manage accounts, and charge customers for account usage monthly based on the number of transactions or the average minimum daily balance. Before any system can be built, the requirements must be gathered, understood, made consistent, and relieved of inconsistencies.

There are many ways to approach this work. We may employ use cases or user stories. We may build use case diagrams with stick figures, write a formalized document, or simply write text. If the system is small enough, we may use 3x5 cards to track each requirement, or simply do it verbally.

Regardless of whether you choose to gather most of your requirements initially or elect to gather them one by one, requirements need to be gathered together and communicated somehow.

Abstracting Solutions

Given a set of requirements, there are often many ways of abstracting a solution to the problem. Abstraction therefore involves wrapping one's mind around the many requirements and choosing to think about the solution in a particular way. For example, we may choose to think about accounts as the result of accumulated transactions, or we may choose to treat a transaction as the primary concept and the account as just the accumulated trace. This step tends not to receive the attention it deserves it involves thinking.

Modeling

Once the analysts have selected an appropriate set of abstractions, the next step is to select a modeling language and/or a metamodel, and then build a model of these abstractions. This model describes and defines the abstracted concepts, and as such is a formalization of knowledge of the subject matter.

Testing the Model

Once the model has been constructed, the next step is to verify that the model is correct. In other words, you need to answer this question: Does the model do what you (your clients) want?

One approach to testing a model is to review it. Unfortunately, checking a model by hand is notoriously error-prone, and there's always the problem of multiple interpretations of the model by different people, especially if a broad metamodel is used. The alternative is to execute the models by generating test cases that set initial conditions and then providing some stimuli that cause the model to produce some output and to change the state of the system. These test cases may be derived more or less directly from the use cases or user stories.