Abstract. In interactive design processes, strategic decisions are made at different levels. To support designers, design support systems need to include corresponding strategic knowledge at these levels. In this paper three levels of strategic interaction and strategic knowledge are identified within a compositional model of design. These levels are identified in reasoning about the manipulation of requirements and their qualifications, reasoning about the manipulation of design object descriptions and reasoning about design process co-ordination. Illustrative examples of these levels of strategic knowledge are specified within the compositional modelling framework DESIRE.
Design is a complex process, in which different types of knowledge play different roles. The nature of requirements, of their qualifications and of the relations between requirements is one aspect of the design process. The nature of a specific design and the identification of its qualities is another. The design process itself, the strategies employed to reason about requirements, design descriptions and their interaction is yet another. Each of these aspects of design entails different types of knowledge and different types of reasoning behaviour. In interactive design, a design support system supports a designer on the basis of knowledge of requirements and their qualifications, knowledge of the object domain and knowledge of the strategies that designers employ.
In interaction with a design support system, a designer changes requirements and qualifications of requirements during the design process on the basis of many factors, including existing (partial) design object descriptions and an increasing level of understanding of specific aspects of the design problem. Which requirements are changed, when and how, depends on the design strategy followed. These changes in requirements, together with the overall strategy, have impact on the different types of strategies in the subsequent design process. The overall design strategy co-ordinates the more specific strategies1. To model such strategies, strategic reasoning, strategic knowledge, and strategic user interaction of different types and levels are required (see also (Oshuga, 1990, 1997; Hori, 1997; Sumi, 1997)).
This paper distinguishes different levels of reasoning, knowledge and interaction and shows how these levels can be modelled at different meta-levels within a compositional architecture. The use of meta-levels for this purpose is also a characteristic of both Hori's and Oshuga's approach to modelling design (Oshuga, 1990, 1997; Hori, 1997). The distinction between meta-levels is essential to the design of design support systems: it provides a means to reason about interactions between a design support system and a designer. One compositional modelling framework in which different meta-levels are explicitly modelled is DESIRE. This compositional development method is briefly described in Section 2. In Section 3, a generic model of design is presented. In Section 4, three levels of strategic knowledge are distinguished. In Sections 5, 6 and 7, examples of specifications of strategic knowledge are presented. The results are briefly discussed in Section 8.
Within the DESIRE framework, compositional (meta-level) architectures for complex reasoning tasks such as design are conceptually modelled, specified and implemented (Brazier, Dunin-Keplicz, Jennings, and Treur, 1995; Brazier, Treur, Wijngaards, and Willems, 1998). Libraries of models are available to support the development of such systems. The compositional development method DESIRE supports the use of both generic models and instantiated models. The types of knowledge distinguished in DESIRE are described below in Section 2.1; a short description of the use of generic models is given in Section 2.2.
During conceptual and detailed design in the DESIRE modelling approach, the following types of knowledge are distinguished: knowledge of task composition, knowledge of information exchange between (sub-)tasks, knowledge of task sequencing, knowledge of task delegation, and knowledge of knowledge structures and their relation to tasks. A short description of these types of knowledge follows; for a more detailed description, see (Brazier, Dunin-Keplicz, Jennings, and Treur, 1995; Brazier, Treur, Wijngaards, and Willems, 1998).
Task Composition, Task Delegation and Knowledge Structures. Task composition includes knowledge of a task hierarchy (tasks and sub-tasks), knowledge of the types of information required as input and resulting as output, and knowledge of the reflective nature of tasks with respect to each other. Each of the tasks is specified as a component (for example, see Figure 1 in Section 3), which is either composed or primitive, and is delegated to one or more agents.
The information types, required as input or generated as output of a task, are specified by explicit naming. The same holds for the knowledge structures (information types and knowledge bases) used internally in a component. During knowledge acquisition appropriate compositional structures for domain knowledge are devised: information types and knowledge bases may be combined in new information types and knowledge bases. Compositional knowledge structures and compositional task structures in principle are defined independently. Their relation is specified by references within each task to the knowledge structures to be used.
Within knowledge structures concepts are required to identify objects and relations distinguished in a domain (domain-oriented ontology), but also to express the methods and strategies employed to perform a task (task-oriented ontology). In detailed design, concepts and relations between concepts are defined in hierarchies and rules based on order-sorted predicate logic. Units of information are represented by the ground atoms defined in the signature. The role information plays within reasoning is indicated by the level of an atom within a component: different (meta)levels may be distinguished. In a two-level situation the lowest level is termed object level, and the second level meta-level. Meta-level information contains information about object level information and reasoning processes; for example, for which atoms the values are still unknown (epistemic information). Similarly, tasks which include reasoning about other tasks are modelled as meta-level tasks with respect to object level tasks. Often more than two levels of information and reasoning occur, resulting in meta-meta-...-level information and reasoning.
Information Exchange between Tasks and Sequencing of Tasks. Knowledge of information exchange between tasks defines the types of information transferred between tasks. For each of the levels of abstraction in the task composition, the relations expressing information exchange between tasks are explicitly specified by information links. For examples of information links, see the arrows in Figure 1.
Task sequencing is explicitly modelled within components by task control knowledge. Task control knowledge includes not only knowledge of which tasks should be activated when and how, but also knowledge of the goals associated with task activation and the extent to which goals should be satisfied. Components may be either continually capable of processing new information (awake) or conditionally capable of processing new information (active), depending on task control knowledge. Comparably links may be either continually capable of transferring new information or conditionally capable of transferring new information, depending on task control knowledge. As a result the need for parallel or sequential processing may be determined dynamically.
Generic agent and task models are used to structure knowledge acquisition. These models are generic with respect to both the task and the domain, and as such can be refined by defining more specific task structures (specialisation, by extending the task hierarchy) and by defining specific domain knowledge (instantiation, by adding detailed specifications of knowledge structures). The generic model of design presented in Section 3 is an example of a generic task model.
A specific task model is most often the result of negotiation with an expert and user: a shared task model is acquired on the basis of existing generic models of the type of tasks required. The shared task model, a mediating model (Ford, Bradshaw, Adams-Webber, and Agnew, 1993) used both to structure knowledge acquisition (in the development phase) and the interaction between the user and the system (when the system is used), is an agreed model: a model agreed to be applicable by both the system designer and the user. In general, three different levels of interaction can be distinguished (Brazier, Treur, and Wijngaards, 1996):
Object level interaction is not uncommon to knowledge-based systems: it entails interaction about factual information, for example, specific facts about a given world situation. The factors on which design decisions are based are often, however, of a slightly different nature. Strategic preferences refer to, for example, goals, heuristics, and assumptions. Such information is meta-information with respect to the factual information on which object level interaction is based. Once a model has been designed (i.e. tasks and knowledge structures defined, interaction, delegation and control specified), a user may decide that the model needs adaptation. Interaction about the re-design of a task model is known as interaction at the level of task modification.
Models of design processes are often based on analyses of design tasks, design systems and designers' approaches (see, for example, (Akin, 1978; Schön, 1983; Pahl and Beitz, 1984; Brown and Chandrasekaran, 1989; Smithers, Corne, and Ross, 1994; Oshuga, 1997)). In this paper, a generic model of design introduced by (Brazier, Langen, Ruttkay, and Treur, 1994) is used to analyse the role of strategic knowledge within design processes. Refined and improved versions of this model have been applied to different types of design (sub-)tasks in a number of domains; for example, conflict management in design (Brazier, Langen, and Treur, 1995), re-design of knowledge-based systems (Brazier, Langen, Treur, and Wijngaards, 1996), elevator configuration design (Brazier, Langen, Treur, Wijngaards, and Willems, 1996) and design rationale (Brazier, Langen, and Treur, 1997). In this generic model of design, as in Oshuga's model of design (Oshuga, 1997), reasoning about requirements, their qualifications and the relations between requirements is distinguished from reasoning about design object descriptions and reasoning about the design process as a whole.
This generic model of design assumes the existence of a problem statement and a more specific list of requirements and qualifications of requirements (including requirements based on a client's needs and desires), in addition to knowledge of relations between requirements, knowledge of the domain objects and knowledge of design strategies. Design object descriptions (DODs) are devised on the basis of requirement qualification sets (RQSs). Requirement qualification sets guide the development of design object descriptions by limiting the space to be explored.
In the generic model, a requirement is a statement about necessary or desired characteristics of the artefact to be designed, whether formulated abstractly (e.g. in terms of needs, desires or wishes) or concretely (e.g. in terms of observable or measurable properties of the artefact). Requirements can often be grouped into sets of requirements which are directly related to a specific view of the artefact to be designed.
Requirement qualifications may be used to define criteria with which a (partial) design object description can be evaluated (e.g. human-friendliness, robustness, modularity, environment-friendliness, etc.). Requirement qualifications can also be used to define preferences on requirements, expressing the relative importance of these requirements. For example, requirements may be qualified as hard, which means they must always be satisfied, or, for example, as soft, which means that their satisfaction is desired but not essential.
Requirements often change during the process of design. Which requirements are considered when depends on the design strategy employed with respect to the manipulation of requirements and their qualifications. An example of a strategy for requirement qualification set manipulation is to focus first on sets of requirements expected to have the largest impact on the design of the artefact.
A completely different strategy will most often be employed for the creation of the design artefact: which factors to consider when is determined by the strategy for design object description manipulation. Partial design object descriptions are extended during design on the basis of additional knowledge and integration of sub-solutions. The design strategy with respect to the design object description determines how this is approached. An example of a design strategy for design object description manipulation is to follow the problem-solving method generate-and-test.
The distinction between requirement qualification set manipulation (RQSM) and design object description manipulation (DODM) is shown in Figure 1; design process co-ordination (DPC) is responsible for the co-ordination of the overall design strategy (see (Brazier, Langen, Ruttkay, and Treur, 1994)).
The result of the design task, a design object description, fulfils a set of requirements and complies with the knowledge known to the design support system. The functionality of the three main components of the generic model, requirement-qualification-set-manipulation, design-object-description-manipulation and design-process-coordination, is described below.
To choose the most relevant subset of requirements, given a current set of requirements and their qualifications, entails consideration of the relevance, importance, and strength of the individual requirements and the relations between requirements. For example, hard requirements must, by definition, hold for the final design object description but are not necessarily imposed continually during design. A set of related hard requirements (e.g. a view) may be grouped together during design. The choices made, the strategy chosen for the determination of the set of requirements to be considered, are based on knowledge of preferences between requirements.
Explicit ranking criteria between preferred sets of requirements are sometimes available, but often also other types of strategic knowledge are required. One global strategy is to make a distinction between the sources of a requirement: requirements based on user preferences may be given higher priority than requirements based on default assumptions, which in turn may be given higher priority than requirements which were the deductive consequence of previous requirements (i.e. the approach described by (Haroud, Boulanger, Gelle, and Smith, 1994)).
Creating a design object description on the basis of the requirements imposed, entails determining a strategy for design object description construction. This process is similar to the requirement qualification set manipulation process, although the knowledge differs considerably. Again a possible strategy is to focus on a given number of related elements of the design object (e.g., related to a specific view), on the basis of the related requirements, using the domain knowledge available to adapt the (partial) design object description, resulting in a new (partial) design object description. This process may be repeated for another focus on the design object, and the resulting design object descriptions assessed and compared.
The co-ordination of the design process includes determination (in a dynamic manner) of the overall design strategy, monitoring the progress of the design process, deciding whether to continue or not and if so, where to continue.
Design process co-ordination can provide guidance to the design process in very different ways. For example, it may prescribe precisely what has to be done during the manipulation of requirement qualification sets or design object descriptions. A less dictatorial strategy is to merely describe the desired results of the manipulation processes and to suggest ways to achieve those results.
To support designers, a design support system needs to provide at least two of the three levels of interaction distinguished in Section 2: object level interaction and strategic level interaction. Designers need to be able to influence a design process by providing both facts and strategic considerations (e.g., preferences and objectives). In fact, analysis of design tasks in a number of domains of application has shown that strategic level interaction refers to a broad spectrum of interaction. Different levels of strategic interaction can be distinguished; these levels of interaction correspond to the different levels of reasoning, and the corresponding knowledge, modelled in the generic model of design described above.
In this model, four levels of knowledge are distinguished. At the lowest level, not visible in Figure 2, the object level reasoning and knowledge is defined. At the next three higher levels, strategic reasoning and strategic design knowledge are specified. These levels can be seen as meta-levels with respect to each other; each of the three meta-levels has a semantics that is based, in part, on the processes at the lower level. Figure 2 shows the three meta-levels and the information types within the interfaces of the three main components of the generic model of design.
The object level (hidden within component DODM) includes facts expressing properties of a given design object and domain knowledge on the type of objects to be designed and their environment. The first meta-level includes knowledge of requirements and their qualifications, and meta-descriptions of the DODs. The second meta-level includes knowledge with which to reason about DODs, RQSs and their modifications. The third meta-level includes knowledge with which to reason about overall design strategies: overall design strategies for the entire design process and overall strategies for RQS manipulation and DOD manipulation, respectively.
In the following sections, DESIRE specifications of strategic knowledge and reasoning during the design of a house, given client requirements, environmental requirements and designer requirements, are presented. This example is based on a practical case of design in the Netherlands. Strategic knowledge for the overall design process (at meta-level 3) is presented in Section 5, more specific strategic knowledge for requirement qualification set manipulation (at meta-level 2) in Section 6 and strategic knowledge for design object description manipulation (at meta-level 2) in Section 7.
In the generic task model of design, the component design-process-coordination receives information about the design process itself: design process objectives (including requirements on the design process), status information about the requirement qualification set manipulation process, and status information about the design object description manipulation process. It determines an overall strategy for the design process. In this section, examples of strategic knowledge defined for this purpose are described and specified. The following example is used.
Example. The amount of time available for a design process is assumed to affect the overall strategy employed. If more than 100 hours are (still) available, some creative freedom is possible; if less time is available, a more practical approach is needed. The amount of time allocated to the design process (a requirement on the design process), and the amount of time still available are used to determine the overall design strategy.
Part of the knowledge used to specify the overall strategy is the following:
if is_objective(max_processing_time(T1:
Time_Stamp))
and is_time_currently_spent(T2: Time_Stamp)
then is_time_currently_left(T1: Time_Stamp - T2: Time_Stamp);
if is_time_currently_left(T:
Time_Stamp)
and T: Time_Stamp <= 100:00:00
then is_possible_design_strategy(to_be_practical);
if is_time_currently_left(T:
Time_Stamp)
and T: Time_Stamp > 100:00:00
then is_possible_design_strategy(to_be_explorative);
if is_possible_design_strategy(S:
Overall_Design_Strategy)
and not is_rejected_design_strategy(S: Overall_Design_Strategy)
then is_best_design_strategy(S: Overall_Design_Strategy);
if is_best_design_strategy(S: Overall_Design_Strategy)
then is_current_design_strategy(S: Overall_Design_Strategy);
Depending on the input provided, this knowledge base determines the overall design strategy. If, for example, the input includes:
is_objective(max_processing_time(200:00:00))
is_time_currently_spent(20:00:00)
not is_rejected_design_strategy(to_be_practical)
not is_rejected_design_strategy(to_be_explorative)
then the output includes:
is_current_design_strategy(to_be_explorative).
If the input, however, includes a different objective:
is_objective(max_processing_time(100:00:00))
then the output includes:
is_current_design_strategy(to_be_practical).
Note that the information and knowledge on which this reasoning process is based, is positioned at meta-level 3 in Figure 2. The implications of the choice of either being practical or being explorative for the manipulation of requirement qualification sets, and for manipulation of design object descriptions, are determined by additional strategic knowledge, discussed in Sections 5.2 and 5.3.
An implication of being practical for the manipulation of requirement qualification sets could be to ignore a client's soft requirements (and only take the client's other requirements into account). An implication of being explorative could be to re-negotiate requirements. This strategic knowledge used within the component RQSM, at meta-level 3 in Figure 2, is specified as follows:
is_supported_by_RQSM_strategy(to_be_practical,
to_exclude_requirements_with_qualification(qlf(client, soft)));
is_supported_by_RQSM_strategy(to_be_explorative, to_renegotiate_requirements);
if is_current_design_strategy(S1:
Overall_Design_Strategy)
and is_supported_by_RQSM_strategy(S1: Overall_Design_Strategy,
S2: RQSM_Strategy)
and not is_rejected_RQSM_strategy(S2: RQSM_Strategy)
then is_best_RQSM_strategy(S2: RQSM_Strategy);
if is_best_RQSM_strategy(S: RQSM_Strategy)
then is_current_RQSM_strategy(S: RQSM_Strategy);
If the overall design strategy is to be practical, then the output of strategic reasoning with the above specified strategic knowledge includes:
is_current_RQSM_strategy(to_exclude_requirements_with_qualification(qlf(client, soft))).
Otherwise, if the overall design strategy is to be explorative, then the output includes:
is_current_RQSM_strategy(to_renegotiate_requirements).
The implications of being practical or being explorative for the manipulation of the design object description are also determined by additional strategic knowledge. An implication of being practical could be to use an existing design. An implication of being explorative could be to generate a new design from scratch. This strategic knowledge used within the component DODM, at meta-level 3 in Figure 2, is specified as follows:
is_supported_by_DODM_strategy(to_be_practical, to_try_reusing_an_earlier_design);
is_supported_by_DODM_strategy(to_be_explorative, to_generate_a_design_from_scratch);
if is_current_design_strategy(S1:
Overall_Design_Strategy)
and is_supported_by_DODM_strategy(S1: Overall_Design_Strategy,
S2: DODM_Strategy)
and not is_rejected_DODM_strategy(S2: DODM_Strategy)
then is_best_DODM_strategy(S2: DODM_Strategy);
if is_best_DODM_strategy(S: DODM_Strategy)
then is_current_DODM_strategy(S: DODM_Strategy);
If the overall design strategy is to be practical, then the output of strategic reasoning with the above-specified strategic knowledge includes:
is_current_DODM_strategy(to_try_reusing_an_earlier_design).
Otherwise, if the overall design strategy is to be explorative, then the output of strategic reasoning with the above-specified strategic knowledge includes:
is_current_DODM_strategy(to_generate_a_design_from_scratch).
After the overall design strategy has been determined and has provided input for the manipulation of requirement qualification sets and for the manipulation of design object descriptions, the resulting process is evaluated, and, if required, modified. In this specific example, this includes knowledge to determine whether the allocated amount of time has been used or not, as well as knowledge to determine whether the current design strategy has proved to be successful, specified as follows:
if is_objective(max_processing_time(T1:
Time_Stamp))
and is_time_currently_left(T2: Time_Stamp)
and T2: Time_Stamp >= 00:00:00
and is_objective(is_RQS_to_be_used(S1: RQS_Name))
and is_result_of_RQS_modification_to(S2: RQS_Name, S1:
RQS_Name)
and is_solution_for(D: DOD_Name, S2: RQS_Name)
then is_fulfilled(max_processing_time(T1: Time_Stamp));
if is_objective(O:
Design_Objective)
and is_fulfilled(O: Design_Objective)
and is_current_design_strategy(S: Overall_Design_Strategy)
then is_successfully_handled_by(O: Design_Objective, S:
Overall_Design_Strategy);
Strategic decisions related to the manipulation (determination of foci and modifications) of requirement qualification sets are modelled and specified explicitly. In this section an example is used to illustrate a few of the types of strategic knowledge involved in reasoning about the modification of requirement qualification sets. How this knowledge is used depends on the overall design strategy determined by design process co-ordination. The example shows a case, in which strategic knowledge is required for the selection of one of the alternatives generated for modification of the current RQS.
Example. A house is to be built on a plot with a road to its west. During preliminary design of this house one of the aspects considered is the volume of the house. The client specifies his/her needs and desires with respect to floor space and cost. In interaction with the architect, this is translated into a requirement for a volume of between 255 and 265 m3. (Dutch architects use requirements for cubic meters, rather than square meters, as a basis for their designs.) Another aspect is the position of the front door. Given the location of the house, the client indicates a preference for the front door to face west (to provide easy access for guests). The last aspect for which the client provides input, concerns the outer walls: the outer walls are not to be built from synthetic material.
The architect, knowing that the prevailing wind comes from the west, would prefer the front door to face south. The two options for the position of the front door are related to two different criteria: the criterion of accessibility (initially put forward by the client) and the criterion of protection against out-door conditions (put forward during the design process by the architect). According to the first criterion, the best option would be for the front door to face west. According to the second criterion, the best option would be for the front door to face south. To make a strategic decision, knowledge is needed about which optimisation criterion is preferred. The architect has a preference for the criterion of protection. For the material of the outer walls the architect takes two criteria into account: durability and aesthetic value. The material brick scores best on durability, wood scores best on aesthetic value. The architect has a preference for durability above aesthetic value.
In this example, the requirement initially imposed by the environment is the following:
is_qualified_requirement(QR00, qlf(environment, hard), road_west)
The requirements initially put forward by the client are expressed as follows (where criteria are modelled as qualifications of the empty requirement tuple [ ]):
is_qualified_requirement(QR01, qlf(client, hard),
volume_is_between_255_and_265m3)
is_qualified_requirement(QR02, qlf(client, hard), not(synthetic_outer_walls))
is_qualified_requirement(QR03, qlf(client, soft), front_door_west)
is_qualified_requirement(QR04, qlf(client, accessibility_optimality),
[ ])
The requirements put forward by the designer during the design process are expressed as:
is_qualified_requirement(QR05, qlf(designer, soft),
front_door_south)
is_qualified_requirement(QR06, qlf(designer, protection_optimality),
[ ])
is_qualified_requirement(QR07, qlf(designer, accessibility_optimality),
[ ])
is_qualified_requirement(QR08, qlf(designer, preferred_over),
[protection_optimality, accessibility_optimality])
is_qualified_requirement(QR09, qlf(designer, durability_optimality),
[ ])
is_qualified_requirement(QR10, qlf(designer, aesthetic_value_optimality),
[ ])
is_qualified_requirement(QR11, qlf(designer, preferred_over),
[durability_optimality, aesthetic_value_optimality])
The strategic knowledge needed to implement the two design strategies for the manipulation of requirement qualification sets described above in Section 5, namely to ignore the client's soft requirements, respectively to re-negotiate and extend the client's set of requirements, are described below in more detail.
The strategic knowledge specified in Section 5 for a time-constrained design process, translated the overall strategy to be practical into the strategy for the manipulation of requirement qualification sets to ignore all soft requirements put forward by a client. All environmental requirements and designer requirements are considered. The strategic knowledge needed to implement this approach is straight-forward.
From the set of initial qualified requirements imposed by the client on the design process, the subset of soft requirements is determined and explicitly marked as rejected. When the current requirement qualification set manipulation strategy includes:
is_current_RQSM_strategy(to_exclude_requirements_with_qualification(qlf(client, soft)))
then the following knowledge suffices to exclude soft client requirements:
if to_exclude_requirements_with_qualification(qlf(S:
Source, Q: Qualification))
and is_current_qualified_requirement(QR: Qualified_Requirement,
qlf(S: Source, Q: Qualification), T: Requirement_Tuple)
then is_rejected_qualified_requirement(QR: Qualified_Requirement);
When the current requirement qualification set manipulation strategy also includes:
to_include_requirements_with_source(environment)
to_include_requirements_with_source(designer)
then the following knowledge can be used to select all environmental requirements and all designer requirements (with application of the Closed World Assumption (CWA) on the predicate is_rejected_qualified_requirement):
if to_include_requirements_with_source(S:
Source)
and is_current_qualified_requirement(QR: Qualified_Requirement,
qlf(S: Source, Q: Qualification), T: Requirement_Tuple)
then is_potentially_selected_qualified_requirement(QR:
Qualified_Requirement);
if is_potentially_selected_qualified_requirement(QR:
Qualified_Requirement)
and not is_rejected_qualified_requirement(QR: Qualified_Requirement)
then is_selected_qualified_requirement(QR: Qualified_Requirement);
Qualified requirements are marked as 'potentially selected' first, as at the same time (and for other reasons) they may also have been marked as rejected. This knowledge is used for reasoning at meta-level 2 in Figure 2 within the component RQSM, the level at which knowledge about strategic decisions on specific choices between qualified requirements is specified.
The strategic knowledge specified in Section 5 for a non time-constrained design process, translated the overall design strategy to be explorative into the strategy for the manipulation of requirement qualification sets to re-negotiate (qualified) requirements. Since the client and the designer do not agree in their preference about the position of the front door, these requirements are good candidates for re-negotiation.
Reasoning about the choice of requirements at a given point in a design process requires knowledge specified at meta-level 2. For example, the strategic knowledge that if an overall best option (considering all relevant criteria) exists it is to be selected, can be specified as follows (with a Closed World Assumption on the predicate is_disqualified_criterion and by defining the sort Criterion as a subsort of the sort Qualification):
if to_renegotiate_requirements
and is_current_qualified_requirement( QR: Qualified_Requirement,
C: Criterion, [ ])
then is_potentially_relevant_criterion(C: Criterion);
if is_potentially_relevant_criterion(C:
Criterion)
and not is_disqualified_criterion(C: Criterion)
then is_relevant_criterion(C: Criterion);
if to_renegotiate_requirements
and is_qualified_requirement( QR: Qualified_Requirement,
Q: Qualification, T: Requirement_Tuple)
and T: Requirement_Tuple <> [ ]
then is_potentially_selected_qualified_requirement(QR:
Qualified_Requirement);
if is_potentially_selected_qualified_requirement(QR1:
Qualified_Requirement)
and is_potentially_selected_qualified_requirement(QR2:
Qualified_Requirement)
and is_relevant_criterion(C: Criterion)
and entails_qualified_requirement_selection_ranking(C:
Criterion, [QR1: Qualified_Requirement, QR2: Qualified_Requirement])
then is_rejected_qualified_requirement(QR2: Qualified_Requirement);
Here the knowledge about comparison of qualified requirements for a given criterion is assumed to be provided by an RQS assessment sub-task. Application of the Closed World Assumption to the predicate is_rejected_qualified_requirement provides a set of non-rejected candidates for 'overall best option'. If this set is not empty, an overall best option can be selected from this set (by means of the knowledge specified at the end of Section 6.1). If an overall best option exists, then by strategic reasoning with the knowledge specified above, an option will be determined that is optimal with respect to all relevant criteria. Note that in this case no knowledge on preferences between criteria is required.
If no optimal option exists (i.e., if each option is beaten by another option on at least one relevant criterion), then only a pareto-optimal option can be selected (i.e., an option for which no other option exists which beats it for at least one criterion and which is not beaten on all other criteria). Strategic knowledge to determine such a pareto-optimal option can take into account preferences between criteria, as is specified below:
if is_potentially_selected_qualified_requirement(QR1:
Qualified_Requirement)
and is_potentially_selected_qualified_requirement(QR2:
Qualified_Requirement)
and is_potentially_relevant_criterion(C1: Criterion)
and is_potentially_relevant_criterion(C2: Criterion)
and is_current_qualified_requirement(
QR: Qualified_Requirement, preferred_over, [C1: Criterion,
C2: Criterion])
and entails_qualified_requirement_selection_ranking(C1:
Criterion,
[QR1: Qualified_Requirement, QR2: Qualified_Requirement])
and entails_qualified_requirement_selection_ranking(C2:
Criterion,
[QR2: Qualified_Requirement, QR1: Qualified_Requirement])
then is_disqualified_comparison_criterion_for(C2: Criterion,
QR1: Qualified_Requirement, QR2: Qualified_Requirement);
Note that the sort Criterion is also defined as a subsort of the sort Requirement. To yield a ranking of qualified requirements, the following knowledge can be used (with application of the Closed World Assumption on the predicate is_disqualified_comparison_criterion_for and the predicate entails_qualified_requirement_selection_ranking):
if is_potentially_selected_qualified_requirement(QR1:
Qualified_Requirement)
and is_potentially_selected_qualified_requirement(QR2:
Qualified_Requirement)
and not is_disqualified_comparison_criterion_for(C:
Criterion, QR2: Qualified_Requirement, QR1: Qualified_Requirement)
and not entails_qualified_requirement_selection_ranking(C:
Criterion, [QR2: Qualified_Requirement, QR1: Qualified_Requirement])
then is_as_least_as_good_as(QR1: Qualified_Requirement,
QR2: Qualified_Requirement);
To remove qualified requirements that are 'worse' than others, the following knowledge can be used (with application of the Closed World Assumption on is_as_least_as_good_as):
if is_potentially_selected_qualified_requirement(QR1:
Qualified_Requirement)
and is_potentially_selected_qualified_requirement(QR2:
Qualified_Requirement)
and not is_as_least_as_good_as(QR1: Qualified_Requirement,
QR2: Qualified_Requirement)
then is_rejected_qualified_requirement(QR1: Qualified_Requirement);
If no overall best solution exists, strategic reasoning with this knowledge (and the knowledge specified at the end of Section 6.1) determines as a solution a requirement that is assessed to be best for a most preferred criterion, given a choice between a number of soft requirements and a preference relation between the relevant criteria.
In the above example, initially three client requirements are considered: one on the volume of the house, one on the material for the outer walls, and one on the position of the front door. The environmental requirement on the position of the plot and the designer's requirements as specified in Section 6.1 are also considered. The architect can re-negotiate the client's preference on the basis of these criteria. In the example of the position of the front door, the preference of protection over accessibility is agreed, so the output of this negotiation process is the architect's preference, namely that the front door faces south.
Reasoning at meta-level 2 determines that the architect's requirement with respect to the position of the front door is selected:
is_selected_qualified_requirement(QR05)
and that the client's requirement with respect to the position of the front door is dropped. All other client requirements are selected.
Strategic decisions related to the modification (determination of foci and modifications) of design object descriptions are also modelled and specified explicitly. In this section the same example used above in Section 6 is used to illustrate a few of the types of strategic knowledge involved in reasoning about the modification of design object descriptions. How this knowledge is used depends on the overall design strategy determined by design process co-ordination.
The strategic knowledge needed to implement the two possible design strategies for the manipulation of design object descriptions described above in Section 5, namely to re-use an existing design, if possible, respectively to design from scratch (depending on the design process objectives), are described below in more detail.
The strategic knowledge specified in Section 5 for a time-constrained design process, translated the overall design strategy for the entire design process to be practical into the need to re-use an existing design, if possible, for the manipulation of design object descriptions. This design strategy, together with the requirements (derived using a strategy ignoring the client's soft requirements; see Section 6), are input for the DODM process. The strategic knowledge needed to implement this strategy could rely on case-based reasoning, using all requirements to index retrieval. In this example, however, for reasons of explanation, retrieval from the library of existing design object descriptions is based on the environment requirements only. On the basis of the environment requirement
is_qualified_requirement(QR00, qlf(environment, hard), road_west)
an existing design is retrieved from the library that indeed has the right orientation for a plot with an adjacent road directly to its west. The following knowledge at meta-level 2 is used to specify this choice:
if to_try_reusing_an_earlier_design
and is_current_qualified_requirement(QR: Qualified_Requirement,
qlf(environment, hard), [R: Requirement])
and exists(DOD1: DOD)
and satisfies(DOD1: DOD, R: Requirement)
then candidate_DOD_to_be_retrieved(DOD1: DOD);
Existing designs are examined, one-by-one, to determine whether or not they fulfil the other requirements. A number of existing designs are found for houses with a volume of approximately 260 m3, but not one for a house with a volume of approximately 260 m3 and non-synthetic outer walls. The following possible modification options are generated for the first design of a house found with a volume of between 255 and 265 m3:
is_potentially_selected_DOD_option(is_made_of(outer_walls,
wood))
is_potentially_selected_DOD_option(is_made_of(outer_walls, brick))
The choice of material depends on the preference relation between the criterion of maximal durability and the criterion of aesthetic value. In this example this choice is made using the architect's preference for durability, specified in Section 6, and relevant strategic knowledge. Strategic knowledge that if an overall best option exists (i.e., best in all relevant criteria) it is to be selected, is specified using knowledge (and a closed world assumption on some of the predicates) very similar to the knowledge depicted in Section 6.2.
Strategic knowledge also includes knowledge that specifies that if not one of the options is the overall best option then the acceptable options are to be determined (based on preferences between criteria). This is also specified by knowledge very similar to the knowledge depicted in Section 6.2.
In this case the choice for durability results in the choice for the option with brick outer walls. Note that in this variant of the design process, no requirements are imposed on the position of the front door. The position of the front door is determined by the position of the front door in the retrieved design; the door may, for example, face south.
The strategic knowledge specified in Section 5, for a non time-constrained design process, translated the overall design strategy to be explorative into the overall DODM strategy to design from scratch for the manipulation of design object descriptions. The requirements derived using the strategy to re-negotiate requirements in Section 6, are assumed to be imposed on this process.
During preliminary design a decision has to be made whether a bungalow or a two-storey building is preferred. Given the requirement that the total volume be between 255 and 265 m3, the choice is between a bungalow with a floor area of 100 m2 and a two-storey house with a floor area of 50 m2 (in both cases assuming a floor height of 2.60 m).
The relative importance of the two criteria involved, average floor space/room and insulation value, is crucial. If the first criterion is more important, the best option is the bungalow (because in a bungalow no space needs to be reserved for a staircase). If the second criterion is more important, the best option is the two-storey house (because the sum of the outer wall area and the roof area of the two-storey house is less than that of the bungalow). To obtain information about these optimisation criteria and the preference between them, the RQS manipulation process becomes active. The following (soft) designer requirements are selected:
is_current_qualified_requirement(QR12, qlf(designer,
room_area_optimality), [ ]))
is_current_qualified_requirement (QR13, qlf(designer, insulation_optimality,
[ ]))
is_current_qualified_requirement (QR14, qlf(designer, preferred_over,
[insulation_optimality, room_area_optimality]))
The strategic DOD modification knowledge determines, in this case, that a bungalow is preferred.
The only requirement with respect to material choice, is the requirement that the outer walls be made from non-synthetic material. Given the strategic knowledge on material choice and the architect's preference for durability (see Section 6), the choice for brick outer walls, is made.
The required position of the front door, namely facing south, is one of the main factors involved in the process of determining the position of the building on the plot.
Design entails strategic reasoning at different levels, for example, to determine requirements on the design process itself (design process objectives), to determine preferences between options and criteria, to assume values for specific attributes and to choose between design options. In addition to object-level interaction, three (meta-)levels of strategic reasoning are distinguished in this paper. As strategic interaction with the designer may be desirable at each of these levels, design support systems need to be designed to support such interaction.
At the highest level, design process objectives are determined, as are the implications for the overall design strategy for the entire design process, the manipulation of requirement qualification sets, and the manipulation of design object descriptions. Requirements on the design process, such as time constraints imposed by a client, may be acquired in interaction with the designer.
At the next level down, strategic reasoning about requirements determines which requirements are to be considered, following a given overall RQS manipulation strategy (determined one level higher). Interaction with the designer is possible on, for example, preference relations between requirements, inconsistent requirements, and a preferred focus.
The same strategic level determines which aspects of a design object are to be considered, following a given overall DOD manipulation strategy (determined one level higher) and a set of requirements and their qualifications. Interaction with the designer may include selection of a most preferred design or a preferred focus.
Note that each level of reasoning influences the lower levels of reasoning. The highest level determines the overall design process strategy and the implications for the overall strategy for RQS manipulation and DOD manipulation. The next level down determines which (modifications of) requirements and qualifications, and which (modifications of) design object descriptions, are to be considered, given the overall RQS manipulation strategy and the overall DOD manipulation strategy.
The corresponding meta-levels of strategic knowledge are discussed and illustrated in this paper for the generic model of design. The DESIRE framework provides a means to explicitly model and specify such knowledge as well as the strategic reasoning involved. Examples of strategic knowledge at each of these levels are specified, illustrating the flexibility that meta-representations provide. In current research, task-level interaction for re-design systems is a subject of study.
Akin, Ö. (1978). How do architects design?, in J.-C. Latombe (Ed.), Artificial Intelligence and Pattern Recognition in Computer Aided Design, pp. 65-119, Amsterdam: North-Holland.
Brazier, F.M.T., Dunin-Keplicz, B., Jennings, N.R., and Treur, J. (1995). Formal specification of multi-agent systems: a real-world case, in V. Lesser (Ed.), Proc. First Int. Conference on Multi-Agent Systems (ICMAS'95), pp. 25-32, Cambridge: MIT Press. Extended version (1997) in M. Huhns and M. Singh (Eds.), Int. J. Cooperative Information Systems, Special Issue on Formal Methods in Cooperative Information Systems: Multi-Agent Systems, Vol. 6, pp. 67-94.
Brazier, F.M.T., Langen, P.H.G. van, Ruttkay, Zs., and Treur, J. (1994). On formal specification of design tasks, in J.S. Gero and F. Sudweeks (Eds.), Artificial Intelligence in Design '94, pp. 535-552, Dordrecht: Kluwer Academic Publishers.
Brazier, F.M.T., Langen, P.H.G. van, and Treur, J. (1995). Modelling conflict management in design: an explicit approach, in I.F.C. Smith (Ed.), AIEDAM, Special Issue on Conflict Management in Design, Vol. 9, No. 4, pp. 353-366.
Brazier, F.M.T., Langen, P.H.G. van, and Treur, J. (1997). A compositional approach to modelling design rationale, in P.W.H. Chung and R. Bañares-Alcántara (Eds.), AIEDAM, Special Issue on Representing and Using Design Rationale, Vol. 11, No. 2, pp. 125-139.
Brazier, F.M.T., Langen, P.H.G. van, and Treur, J. (1998). Strategic knowledge in compositional design models, in J.S. Gero and F. Sudweeks (Eds.), Artificial Intelligence in Design '98, Dordrecht: Kluwer Academic Publishers.
Brazier, F.M.T., Langen, P.H.G. van, Treur, J., and Wijngaards, N.J.E. (1996). Redesign and reuse in compositional knowledge-based systems, in P.M. Wognum and I.F.C. Smith (Eds.), Knowledge Based Systems, Special Issue on Models and Techniques for Reuse of Designs, Vol. 9, pp. 105-118.
Brazier, F.M.T., Langen, P.H.G. van, Treur, J., Wijngaards, N.J.E., and Willems, M. (1996). Modelling an elevator design task in DESIRE: the VT example, in A.Th. Schreiber and W.P. Birmingham (Eds.), Int. J. Human-Computer Studies, Special Issue on Sisyphus-VT, Vol. 44, pp. 469-520.
Brazier, F.M.T., Treur, J., and Wijngaards, N.J.E. (1996). Modelling interaction with experts: the role of a shared task model, in W. Wahlster (Ed.), Proc. Twelfth Europ. Conference on AI (ECAI'96), pp. 241-245, Chichester: John Wiley and Sons.
Brazier, F.M.T., Treur, J., Wijngaards, N.J.E., and Willems, M. (1998). Temporal semantics of complex reasoning tasks. Data and Knowledge Engineering.
Brown, D.C. and Chandrasekaran, B. (1989). Design Problem Solving: Knowledge Structures and Control Strategies, Research Notes in Artificial Intelligence, London: Pitman.
Ford, K.M., Bradshaw, J.M., Adams-Webber, J.R., and Agnew, N.M. (1993). Knowledge acquisition as a constructive modeling activity, in K.M. Ford and J.M. Bradshaw (Eds.), Int. J. Intelligent Systems, Special Issue on Knowledge Acquisition as Modeling, Vol. 8, No. 1, pp. 9-23.
Haroud, D., Boulanger, S., Gelle, E., and Smith, I.F.C. (1994). Strategies for conflict management in preliminary engineering design. In Smith, I.F.C. (Ed.), Proc. AID '94 Workshop on Conflict Management in Design, Lausanne, Switzerland.
Hori, K., (1997). Where is, what is and how can we use strategic knowledge, in L. Candy and K. Hori (Eds.), Proc. First Int. Workshop on Strategic Knowledge and Concept Formation, Loughborough University, UK.
Ohsuga, S. (1990). Framework of knowledge-based systems: multiple meta-level architecture for representing problems and problem solving processes, Knowledge Based Systems, Vol. 3, No. 4, pp. 204-214.
Oshuga, S., (1997). Strategic knowledge makes knowledge based systems truly intelligent, in L. Candy and K. Hori (Eds.), Proc. First Int. Workshop on Strategic Knowledge and Concept Formation, Loughborough University, UK.
Pahl, G., and Beitz, W. (1984). Engineering design, New York: Springer-Verlag.
Schön, D.A. (1983). The Reflective Practitioner: How Professionals Think in Action, London: Temple Smith.
Smithers, T., Corne, D., and Ross, P. (1994). On computing exploration and solving design problems, in J.S. Gero and E. Tyugu (Eds.), Formal Design Methods for CAD, pp. 293-313, Amsterdam: Elsevier.
Sumi, Y. (1997). Supporting the acquisition and modelling of requirements
in software design, in L. Candy and K. Hori (Eds.), Proc. First
Int. Workshop on Strategic Knowledge and Concept Formation,
Loughborough University, UK.