Problem solving methods are procedures that organize and execute the model construction activities. The methods thus focus on how the information in the domain models should be used to guide the construction of the appropriate case models.
The methods actually do two things. First, they impose tasks on the different activities in the model dependency diagrams. We have already analyzed these tasks in detail in section 3.2. Second, a method imposes a control structure on the various tasks and subtasks. This information is represented in ``control diagrams''. In these diagrams tasks are represented as nodes while the vertices indicate the various possible flows of control between these tasks.
At the top level of the task structure we find the method ``decompose-solve-recompose'' that has been characterized in [Chandrasekaran1990] as ``design-by-decomposition''. As indicated in section 3.2 there were three subtasks: (i) decompose, (ii) solve and (iii) recompose. The method imposes a sequential control structure which we indicate using the following control diagram (figure 25). Note that this is actually a degenerate form of the more general case. In our case, the decomposition can be done in advance. In many applications partial decompositions will be intermixed with the development of (partial) solutions and/or recompositions.
In section 3.2, we have decomposed the task ``decompose problem into subproblems'' into three major subtasks: ``determine problem type'', ``decompose 1'' and ``decompose 2''. The tasks ``determine problem type'' and ``decompose 1'' only need to be executed once. For the task ``decompose 2'', we will have an iteration since the expert has to decompose every problem at the first level of the problem decomposition hierarchy (figure 6). Also note that the task ``decompose 1'' is not always executed. This is the case when the initial problem only contains trains that belong to one and the same passenger relation. In addition, it is also possible that there is no decomposition at all. This is the case when the initial problem contains trains that (i) all belong to the same relation and (ii) have the same characteristic. Figure 26 illustrates the resulting control diagram for this problem solving method.
Solving a subproblem amounts to selecting an engine and specifying the sequence of trains that will be driven by that engine. We therefore find an iteration until all the trains have ended up in the sequence that belongs to a particular engine (figure 27).
The specification of a sequence of trains that will be driven by one engine was described by means of two subtasks. The expert will first select the first train and then iteratively add the other trains to the same sequence. This yields the control diagram depicted in figure 28.
As was the case with the decomposition, we have introduced two tasks to represent the re-composition of solutions: ``re-compose 1'' and ``re-compose 2''. Whether these tasks will actually be executed depends on the decompositions that have taken place. If no decompsosition was needed, then no re-composition is required. Also note that the task ``re-compose 1'' needs to be executed for the solutions of the subproblems of the problems that are at the first level of the problem decomposition hierarchy. The task ``re-compose 2'' is only executed once since the solutions for the subproblems at level one of the problem decomposition hierchy are combined into a single solution for the initial problem. The control diagram which is imposed in these tasks is shown in figure 29.
___________________________________________________