Specification Procedure

Internally, the entire process of drafting a specification is repetitive, because it usually takes numerous iterations to find the flaws and iron them out. The preliminary brainstorming takes place during the sketching phase. Here, ideas are collected and described informally. Then, a rationalization phase can take place, to check for consistency—internally and with existing requirements. Each of the valid options can then be formalized as necessary by converting the sketch into a computer-friendly specification using a KR formalism. Another round of rationalization may optionally take place, because the choice of KR can affect the compliance of the model with requirements. We can repeat the process until we're happy with the results, and are ready to start the implementation.

Sketching

Generally, drafting a few options first is a good idea. These can be complete models, including ideas for inputs and outputs as well as the overall concept, or just ideas for one specific aspect. Initially, these ideas can remain vague—mainly because considering everything in detail is wasteful, but we should feel free to refine each sketch at this stage if it helps.

Role of Sketching

As mentioned, there are three different aspects of the problem we need to think about. Here are some practical tips to get us on the right track:

• Context— Deciding about the context of the problem is often dependent on the design and implementation of the surrounding software. What goes on behind the interfaces needs to be understood before the problem can be solved; because the design is hierarchical, we need to understand how the higher levels work. Which variables are involved directly, and how can their complexity be minimized to simplify the task?

• Input— This stage selects the relevant inputs. To pick appropriate information, thinking about this from a human point of view can be helpful; what information does a human use in this case? Alternatively, what variables are necessary for a programmer to solve this problem?

• Output— The output can be handled in a similar fashion to the input. However, this part is often much easier; it is usually obvious how a problem can be decomposed into a sequence of primitive actions. If it isn't clear, we need to do a little more research on the topic!

Although there is some dependency between these three components, we can treat them separately during this phase for additional simplicity.

Inspiration

Gathering ideas for sketches will become much easier as our experience grows, although initially inspiration can be harder to find. The following sources can help us get started, or find better approaches:

• Active research is the primary source of information. Look through academic journals or related conference proceedings. Check the web for related tutorials and articles.

• Reading around is one of the best alternatives. Keep an eye on the news for developer interviews and project postmortems, giving us a good idea of how colleagues handle the problem. Browsing the web can be "work"!

• Related initiatives often are great sources of help. By investigating related open source projects and reading through any code from SDK, we can find great reference implementations.

• Borrowing ideas from other domains is one of my personal favorites. This isn't always possible, but it is relatively satisfying when it works out.

Creating sketches can take time, because there are many things to consider. It can sometimes be best to leave the problem aside for some time, which provides extra clarity when returning to it later.

Formalizing

During the sketching phase, drafts, partial insights, and rough thoughts have been collected. From these, complete models can be formed. This can be achieved by combining our partial ideas if necessary (for instance, one possible input with this output). Now each part is ready to be formally specified. If this is the first model, we'll probably have to start from scratch; otherwise, we may reuse our previous work.

A complete formal model is a draft specification of the task that could become officially accepted. It consists of documented decisions about the KR and data formats of the inputs, outputs, and context. If it does become accepted, we can and should refine the documentation and polish it up; it will come in handy later.

Knowledge Representation and Data Structures

This phase involves selecting a KR language that is complete enough to represent the environment, flexible enough to extend, and efficient enough to manipulate.

However, this is only part of the formalization, because low-level C++ representations need to be considered, too. This problem falls into the category of data structure design. The data can be expressed with basic types int, float, bool, char; compound ones such as std::vector, std::map, std::list; and optionally exotic ones such as boost::any—see Table 9.1.

Table 9.1. Example Data Structures Chosen to Represent the Knowledge at the C++ Level

Knowledge Representation	Data Structure
Symbols	bool class members
Fuzzy symbols	vector<float>
Attribute/value	map<string,boost::any>

Modeling the more elaborate KR (frames or conceptual graphs) requires moderate C++ skills (that is, knowledge of object-oriented programming).

Formalization Process

Being simpler and limited in number, the outputs are often much simpler to formalize before the inputs. Despite their simplicity, the outputs offer great clarity to the problem. When formalizing the outputs first, we can assume all the inputs are valid and the AI is perfect.

By formalizing the inputs next, the rest of the specification quickly falls into place. Admittedly, the inputs are probably the trickiest aspect of the formalization process—and the primary cause of failure in the latter stages. Additional time and care is required for the inputs.

Finally, the supporting variables from the context can be modeled. These also implicitly affect the behavior of both inputs and outputs. However, the context is often defined abstractly rather than explicitly; this is often enough to complete the formalization, and allow the problem to be solved.

Rationalizing

The rationalizing stage involves consciously checking the options to see whether they fit with the requirements. Admittedly, we may constantly have the requirements in the back of our mind anyway, ruling out options as they come up. However, this generally limits our creativity of brainstorming and causes potentially great ideas to be discarded prematurely. Keeping this phase separate allows the sketching to completely fulfill its potential.

While rationalizing, we need to check a few things for each model, each of which is almost equally important:

• Does the model allow the case studies to be satisfied, and does it match the informal requirement of the solution?

• How does the model affect other requirements, such as hardware and software issues?

• Is the specification consistent with the rest of the design—via interfaces and hierarchical dependencies? If not, how is it affected?

• Are the interfaces flexible enough to handle a variety of implementations, and if not, does it at least match those that are applicable?

Once answered, each of these questions will either validate the specification, or not. In the latter case, the problem must be investigated further; if the cause is identified, the next design iteration can resolve it. Although keep in mind that imperfection is okay! The ideal model can be almost impossible to achieve, so don't hesitate to move on when our design is satisfactory; we will benefit more from the experience in the latter stages.