Some applications of modelling in design

The main objective of this section is to extend the skeleton defined in section 5.2.1. Two applications of knowledge-level modelling are presented to illustrate the challenges investigated in respect to knowledge models. Similarly as it was the case with the review of the current trends in the design support (see section 5.1), the research mentioned in this section is not exclusive. It is a flavour of what kind of problems is investigated at the crossroads of knowledge-level modelling and engineering design. Due to a vast amount of work done, it is virtually impossible to review the whole research because of the sheer number of different approaches and specific applications. Therefore, we opted to give an overview of a couple of large-scale efforts that attempt to model a generic design process.

Instead of repeating what was discussed in the review of the design support tools (section 5.1), we focus on the additional details of the models in design and their relevance to the knowledge-level perspective. Typically, each tool or methodology from section 5.1 corresponds on the knowledge-level to an appropriate model of the design process. However, it should be noted that these ‘procedural models’ of design; i.e. mostly concerned with design as a task, are not the only applications of modelling techniques in design. The work reviewed below includes the research on the Generic Task Model of Design as a representative of a class of generalised procedure- or process-oriented application of knowledge-level modelling (section 5.2.2.1). To complement it, the research that formulated the General Design Theory is reviewed in section 5.2.2.2; this research is a representative of a more

‘declarative’ application of knowledge-level models in design.

5.2.2.1 Generic Task Model of Design

The key idea behind the efforts developing generic task models is the acknowledgement that there are often some problem-independent features typical for a class of tasks. These higher-level knowledge models were already mentioned in the previous section with diagnostics serving as an example.

Regardless of whether a diagnosis is concerned with the medical complaints, shop-floor machine

maintenance or pupils’ performance, certain actions are repeated across the domains, and can be observed in all applications. Therefore, it seems to be reasonable to formalise this domain-independent pattern on an abstract level. This level is often referred to as a task or task-description level, and knowledge models developed on this particular level are in the AI community well known as generic task models (Tansley and Hayball 1993). From a large base of generic task models (or GTM) developed for various specialised tasks, we focus in this section on the GTM for design (GTMD). In particular, the review draws upon research into GTMD conducted by Frances Brazier and the researchers from the Dutch Vrije Universiteit in the past decade (Brazier, van Langen et al. 1996a;

Brazier, van Langen et al. 1996b; Brazier, van Langen et al. 1998).

Figure 5–3. Generic task model of design – structure (Brazier, van Langen et al. 1996b) GTMD assumes that the knowledge of initial requirements is available at the beginning together with the knowledge of design objects and strategies. Requirements may be ordered using a preferential measure, some of them may be necessary, others only preferable. GTMD models the preferences in a module named ‘requirement qualification set manipulation’ (see Figure 5–3). Design strategies known to the designer enable him or her to construct the designed artefact. The same artefact may be described from several different views – GTMD takes this variance in account in form of a specific module for these purposes. In Figure 5–3, this is named ‘design object description manipulation’. The description of a design object (artefact) is mostly incomplete, and it is stepwise extended during the design process, similarly as the set of requirement qualifications. The third module in the figure has the role to co-ordinate design process based on the evaluation of its current state. This module named ‘design process co-ordination’ selects a suitable strategy from the knowledge base for further exploration of a design space. The selected strategy then has an influence on the initial requirement qualifications set, as well as descriptions of the design solutions.

As visible in Figure 5–3, each of the modules can be further decomposed into simpler operations or tasks that are performed during the design process. For instance, in case of requirement manipulation module, four simpler tasks are defined in the following order:

1. (requirement set) modification … this task determines which strategy is chosen for the selection of requirement qualifications, what preferences are applied to the selected relevant requirements, what level of strictness is applicable, and so on;

2. deductive refinement … this task infers what requirements are to be considered having decided on certain preferences earlier, and what possible modifications to the current set are admissible;

3. update of current description … in this step, the selected requirement modifications are enacted and incorporated into the current set of requirement descriptions;

4. update of history … this task keeps track of the development and stepwise refinement of design A similar decomposition and the flow of information is defined for the design object description module; i.e. the module responsible for the development of design solutions. First, candidate objects for the modification are identified; then the actual changes and modifications are deduced. Next, the changes are incorporated into the existing description, and in order to keep a track of the changes, the history record is updated. The update processes for both modules are closely related; i.e. a change performed in one module may have an immediate or delayed impact on the other module.

Between these two modules that work with and manipulate the knowledge of design objects, there is the third module concerned with the knowledge of design actions (see also section 5.2.2.2). The main role of the co-ordinating module is to assess the current state of design, and drawing on this information suggest further amendments in the space of design requirements. In other words, it makes sense to continue with further manipulations of either requirements or solutions, if there is a benefit observable in the development history. For instance, the performance of the design solutions is improving in respect to a particular criterion (e.g. a price). Design process is progressing (not stuck in a deadlock), and there is still an unused potential in the currently active strategy.

Design task, as described and defined by the model in Figure 5–3, is sufficiently abstract to be considered ‘generic’. As such, it may be further adapted and refined for the purposes of specific applications or problems. For instance, Brazier, van Langen et al. (1996b) illustrate the deployment of GTMD for an elevator design in Sisyphus-2 domain, which is a well-known benchmarking case for the domain of knowledge modelling (Yost 1992). To account for the specifics of the elevator design, the generic sub-task of a design description (solution) modification is further refined into separate tasks for the analysis, determination of the modifications, and their implementation. The determination sub-task is further decomposed according to the prevailing method used for the problem solving – e.g. ‘extend-and-revise’ or ‘propose-‘extend-and-revise’. Each of the phases is further detailed into actions that can be readily and directly executed by a problem solver.

The case study of an elevator design shows how a generic task model can be enhanced and refined, when we decide to use it for a specific problem and domain, and choose a suitable problem-solving method. The same case study and a similar breakdown of the knowledge models into task-oriented, domain-oriented, problem-oriented and method-oriented appears also in (Motta and Zdrahal 1998).

According to these authors, the advantage of generic models is that they can be used independently of

each other, and mutually combined almost without any restrictions. For instance, one may re-use a task model of ‘propose-and-revise’ problem-solving method without any commitment to the domain or problem-specific concepts. Of course, this statement has to be taken with a certain degree of scepticism because there are usually constraints as to the applicability of certain methods for particular classes of tasks or domains. However, the idea of such a wide and almost universal re-usability is very challenging, and it became a popular research topic in the past decade (Motta 1997).

GTM in general and GTMD in particular can be very useful in the design of artefacts of a certain type and class. If the various combinations of requirements, fixes, preferences, and parameters are well defined and known in advance, then GTM-s perform very well and very reliably. The fewer irregularities there are in a particular domain, the less work is required in order to tune a generic model into a working procedure. However, in the case when the fixes or preferences are ambiguous or incomplete, and the structure of a design process is changing case to case, it may require a lot of effort to adapt GTM to such an ill-structured problem. Nonetheless, it is still possible to use GTM as a kind of template for the rapid development of the core application, and extend the prototype instead of building the whole application from scratch.

Another useful feature of GTMD is its compositional and decomposable structure. This structure makes it even easier to re-use the modules and/or replace the generic tasks with finer-grained components, as it was the case with the elevator case study. Such modularity enhances the re-usability of the individual components, and any further refinements of GTMD can be seen as replacements of the generic templates/modules with more domain-, problem-, or method-specific ‘plug-ins’.

5.2.2.2 General Design Theory

The origins of the General Design Theory (GDT) can be traced back to the late seventies and early eighties when it was presented first in Japan, later in the rest of the world. The primary source of information for this review is (Tomiyama 1994), where the promises made by the theory when it was launched are evaluated. This concise account of GDT defines it as a knowledge-level theory that is interested with the objects that are conceptually manipulated during the design process. GDT regards design as a mapping from the function space to an attribute space, and associates each object (entity) from the world to an abstract entity concept. The theory assumes that all entities in the world can be described by a finite set of known attributes, and that each ‘real’ entity corresponds exactly to one abstract entity concept. This type of theory is however, rather idealistic and assumes that everything that needs to be known about a design problem at hand is actually known.

As mentioned in section 4.2.1, the assumption of a closed world, in which all objects are well defined, is useful for tackling the incompleteness and variability of the world. Nonetheless, if this were the case and such ‘complete’ knowledge base could be constructed for design, it would deny some of the essential characteristics such as exploration and interpretation. The design would be about straightforward retrieval of the solutions and one-to-one mapping from a complete functional specification to a unique (and the best possible) solution.

In the real world, design is a stepwise refinement of a design solution and underlying constraints. In order to comply with reality, GDT refers to physical laws as a boundary that constrains the

compatibility and applicability of various entities and entity concepts. The iterative development of design solutions to the incompletely described problems is tackled in GDT by the introduction of a concept of ‘meta-model’. This concept represents a more realistic development of design solutions rather than their simple retrieval. It is defined as a finite sub-set of those attributes and values that comply with the physical laws of the ‘real world’. In other words, a meta-model as understood by GDT, is a physically achievable approximation of a design solution. The meta-model is constructed to consider only the objects not contradicting the given constraints. In this aspect, it is reminiscent of the constraint propagation techniques known in the constraint satisfaction (CSP) domain (Kumar 1992). As new attributes are added to the meta-model to satisfy the constraints, the model becomes increasingly more specific, and finally evolves into a final design solution.

GDT and its implementations distinguish between two kinds of knowledge in design. First, it is the knowledge of design objects, and second, it is the knowledge of design actions. At the object level there are several logical operations, such as deduction and abduction, complemented by an extension to the standard logic – circumscription (McCarthy 1980). The operation of circumscription is the interesting one in this triad because it is responsible for the reformation of knowledge in order to resolve a violation of a constraint. However, this seems to be at the same time also a major gap of the GDT model.

As argued in section 4.2.1, the reason is that the circumscription, similarly to the ‘closed world assumption’, only restricts the set of facts. The restriction follows the rule that the objects mentioned as having certain property (e.g. compliance with a constraint) are the only objects that are actually needed to satisfy it (a law or a constraint). Thus, circumscription in GDT can restrict the choice of the attributes and their values to restore the consistency of the solution model with the constraint. Such an approach is more about knowledge refinement than any ‘re-formulation’. Consequently, GDT is unable to come up with a proposal of a solution extension that may violate some of the constraints of the physical laws. Thus, the concepts of Schön’s surprising behaviour or Altshuller’s contradiction are avoided by circumscribing the problem solving theory.

Circumscription narrows the scope of suitable designs by assuming that all the relevant facts were taken into account when performing this operation on the object level. If new knowledge or a fact becomes available, they may easily return the design to its early phases because they may ‘cancel’ the circumscribed inferences⁷. Circumscription is a powerful mechanism bringing common sense into pure logic; nevertheless, it does not have generative powers to convey any new knowledge to go beyond the problematic statement. It is a vehicle for conjecturing, simplifying and constraining the incompletely described discourse. Nonetheless, circumscription may play a significant role in shaping or framing the design problem, as it was mentioned in section 4.2.1.

Back to GDT and its other level of knowledge – knowledge of design actions. According to the theory, this is a purely deductive mechanism comprising a set of rules determining what to do next on the object level. However, apart from the heuristic prediction, GDT says very little about the fact that the ‘action knowledge’ may be occasionally tacit or inarticulate. Designers may approach the problems

7 This is well visible in the ‘interpretation’ of circumscription into plain language that is saying that the objects mentioned are the only ones needed, ‘unless there is something wrong with them’ (McCarthy 1980).

opportunistically and decide on their strategies and next steps on-the-fly. Their ‘strategic’ knowledge (Candy 1998) may involve rather complex reflective processes, and resist attempts to model it as ‘pure deduction’. Yet GDT has many progressive features that comply with the recent cognitive studies of a design practice (see also section 4.1.3). It supports the work in multiple design contexts and maintains the consistency within a context through a truth maintenance system. It acknowledges that the real-world design is a process of solution refinement that rarely begins with a set of complete initial requirements. Finally, it agrees that design is neither synthesis nor analysis (abduction/deduction), but rather a combination of both operations.

On the other hand, what is missing in the theory from our point of view is some kind of ‘talkback’

from the space of solutions back to the space of functions and requirements. The only form of feedback GDT models, is the violation of constraints by a proposed solution model typically followed by the circumscription. The entire model, though being iterative, follows one direction. It is a kind of ‘spiral’

rather than ‘oscillation’ from the functions towards the objects, attributes and values, and vice-versa.

The feedback is limited to the cases of explicit inconsistency of a proposal with the physical laws and constraints (i.e. physical inadmissibility).

GDT acknowledges that new knowledge may be articulated by a designer, but does not actually attend to this articulation. It does not propose any models associating the formulation of new constraints with any reflection or tacit assessment. The designer is a ‘black box’ doing the evaluation, and proposing all modifications to the task specification, and it is not the aim of theory to investigate the details of such reasoning. The role of the theory is to investigate the relevant space of the possible designs, make sure that they are physically admissible, and maintain the logically consistency in the development of the solution. Tomiyama (1994) describes both the original GDT as well as one of its extensions; other extensions can be found e.g. in (Takeda and Nishida 1994).