The Command Processor design pattern, as described in POSA1 (Pattern Oriented Software Architecture, vol 1, Buschman, et al.), separates the request for a service from its execution. The CommandProcessor component manages requests as separate objects, schedules their execution, and provides additional services. The AbstractCommand component defines the interface of all command objects, as a minimum defining the procedure to execute a command. In this way, individual commands can be treated as objects. The derived command will encapsulate a function request. In the implementation that I will be making, there are two multimaps in the CommandProcessor component. The first one is a multimap containing a name and a pointer to an AbstractCommand. This is the multimap illustrated on the following diagram. The second is a multimap containing two names. The first name is the list name and the second is the name of an abstract command contained in the first multimap. This allows a grouping of the commands by a name.
What is missing from this design is a way to have a named list that has a prioritized listing, therefore the AbstractCommand will need to be modified to contain a priority and a strata level. This will become more apparent as the blackboard pattern is introduced.
The Structured Matcher design pattern (from "Structured Matcher" by Eugene Wallingford, 1998) decomposes a complex decision into simpler decisions about relevant factors and then uses decisions about these factors to make the decision. I will be using this design pattern to form the rule pattern portion of a knowledge source. Notice that the Structured Matcher inherits from the AbstractCommand component and therefore is utilized within the Command Processor pattern. The Structured Matcher consists of a directed, acyclic graph of simple matchers. The Simple_Matcher component considers either the values of sub-decisions made by other simple matchers or the values of input data. A data parameter feeds into only one simple matcher. The diagram below is a start on the design of this design pattern. In the Structured_Matcher component there is a multimap containing a name and a pointer to a Simple_Matcher called root. This allows the Structured_Matcher component to have a matcher list to work from. The Simple_Matcher forms a composite design pattern with the Parameter component. By doing this the structured matcher design pattern is composed of a list of hierarchically defined simple matchers. One of the derived classes from the Simple_Matcher component will be a Top matcher, or top of the hierarchy. [Updated]
Finally, I will describe the Blackboard design pattern later. I have succeeded in separating out the Domain and Control knowledge sources and I have almost completed the initial way that it will work. However it is not complete as of this point. I got a little bogged down in the control plan layout and how that interacts with the other design patterns.
