2.1. Argumentation-based representation

Argumentation-based representation is currently the mainstream approach to DR representation. It uses a semiformal graphical format (Buckingham-Shum & Hammond, Reference Buckingham-Shum and Hammond1994) to represent deliberations about design decisions, in which a node represents a DR element such as an issue, option, or argument, whereas a link represents a relationship between the elements. In the node-and-link representation, it uses typed links to interconnect typed nodes (Shipman & McCall, Reference Shipman and McCall1997). With argumentation, designers can easily maintain consistency in decision making, keep track of decisions, and communicate with one another about design reasoning (Regli et al., Reference Regli, Hu, Atwood and Sun2000). One antecedent of argumentation-based models is the issue-based information system (IBIS; Kunz & Rittel, Reference Kunz and Rittel1970), which uses issues, positions, arguments, and their relationships to represent DR. The procedural hierarchy of issue model (McCall, Reference McCall1991) broadens the scope of the “issue” in IBIS and replaces all of the traditional IBIS links by the link “serve.” Question, option, and criteria (MacLean et al., Reference MacLean, Young, Belloti and Moran1991) and DR Language (DRL) models (Lee, Reference Lee1989) are also argumentation-based models. Question, option, and criteria focuses on providing a structure for representation of design alternatives. DRL is a language for representing qualitative decision-making processes, which can comprehensively support designers in making decisions when a problem or goal is complete and clear.

The main research content on the argumentation-based representation model focuses on three areas. The first is the application research of the representation model. Shum et al. (Reference Shum, Selvin, Sierhuis, Conklin, Haley, Nuseibeh, Dutoit, McCall, Mistrik and Paech2006) developed the Compendium tool based on the IBIS model to support capturing and recording rationales in the form of text, hyperlinks, and video. Compendium is used by the NASA's collaborative work team. DRed (Bracewell et al., Reference Bracewell, Ahmed and Wallace2004, Reference Bracewell, Wallace, Moss and Knott2009) is also one of the proposed derivatives of the venerable IBIS concept, which can support designers in recording, revisiting, and understanding previous design solutions. It has been applied in aerospace engineering design as a standard product life cycle management tool at Rolls-Royce. The second area of research is the refining and improvement of the DR model structure. Most argumentation-based approaches provide little mapping information among various DRs and their corresponding artifacts. Liu et al. (Reference Liu, Liang, Kwong and Lee2010) proposed an issue, solution, and artifact layer model for DR representation. In this approach, design solutions link up the issue and artifact components, which offer clues regarding the relationship between problems and their corresponding artifacts. The third area of research is the extension of representation capability. Kuaba (De Medeiros & Schwabe, Reference De Medeiros and Schwabe2008) extends the components of the IBIS model. It defines an ontology vocabulary and a set of rules for recording design decisions. In the Kuaba method, a design decision can be integrated with design evidence and product information, making the recorded DR more complete. Burge and Brown (Reference Burge and Brown2008) extended DRL by using argument ontology to represent and reason requirements, candidate solutions, and evidence. The argument ontology is a predefined set of claim types. Designers can explicitly describe their decisions and integrate them with the evidence and corresponding artifact information. Rockwell et al. (Reference Rockwell, Grosse and Krishmanurty2010) developed a semantic information model for capturing and communicating design decisions, aiming to obtain an explicit documentation of DR through design decisions. In their proposed decision support ontology (DSO), design issues, alternatives, criteria, and evaluation information are identified as key decision-making concepts.

The argumentation-based representation approach extracts key elements of the DR and describes the decision-making process succinctly and effectively. Much progress has been made, and some argumentation-based DR models are already being applied to several industrial projects. However, there are several inherent limitations in such models.

In essence, the argumentation-based approach treats the design as a problem-solving process, assuming that the problem is already understood sufficiently and identified to be analyzed using automatic tools or top-down methods. However, many complex design problems can be characterized as “wicked” problems (Rittel & Webber, Reference Rittel and Webber1973), especially at the initial design stage. They cannot be easily defined, are often solution dependent, and require iteration. These problems need a series of iterative cognition, design, and evaluation cycles to be defined. Subsequently, initial designs based on known data, design principles, assumptions, and constraints are evaluated during the design process. The evaluated results are then used to verify or modify the initial design. Conklin (Reference Conklin2005) introduced an example of a wicked problem related to a new car design: the marketing department is asking for a design that emphasizes side-impact safety. One approach to making a safer car would be to add structural support in the doors to make the car safer from side impact. This can be regarded as an initial design problem. However, it turns out that the additional door structure doubles the cost of the door, makes the doors heavier and harder to open and close, changes the fuel mileage and ride, and requires an adjustment to the suspension and braking systems. Making the doors stronger leads to other design problems, which interact with each other and require designers’ iterative cognition to understand and adjust to what the problem is that needs to be solved during the solution developing process. Therefore, every solution that is offered exposes new aspects of the problem, requiring further adjustments of the potential solutions. Thus, there is no definitive statement of “the problem.”

According to Sim and Duffy's (Reference Sim and Duffy2003) design activity model, the existing design agent's knowledge and the initial design goal serve as inputs to a design activity resulting in a design solution that may satisfy some design goals. In addition, the output of each design activity therefore contributes to a change in the knowledge of the design. As such, the design agent acquires additional knowledge of the design. With the acquired knowledge, the design agent may in turn justify the design goal and the next design activity to bring the design nearer to the final solution. Similarly, Hatchuel and Weil (Reference Hatchuel and Weil2009) proposed a unified design theory, concept–knowledge theory, which argues that “the generation of new objects and new knowledge” is the distinctive feature of designs rather than the dynamic mapping between required functions and selected structures. It emphasizes the generation of objects unknown at the beginning of the process and whose existence could be guaranteed by knowledge that may be discovered during the process. Thus, with the occurrence of the new knowledge and the new objects, the design process is no longer just a problem-solving process but is an iterative and evolving learning process influenced by actual design operations and current design contexts, where designers modify and shift the problems and solutions over time. The problem solving and learning are tightly intertwined, and this evolving design cycle produces a wealth of data and knowledge that forms the rationale for the final design.

Therefore, the argumentation-based approach cannot handle wicked problems adequately because it only provides designers with static issues, options, and arguments for definite problems. It is only an accumulation of discontinuous problem-solving segments. Lack of the dynamic evolvement of design problems, options, actual design operations, and design contexts limits its expressive ability for a complete DR. Furthermore, during a design process, many design problems depend on and influence each other, as shown in the example of the new car design. The argumentation-based approach ignores interactive relationships among design problems, in which the issue is treated independently. This may inevitably result in the loss of important information about a design problem.

2.2. Intent-driven representation

Design intent describes the objectives, plans, and desires that stimulate and instruct a designer to deliberate a design process. Different from the argumentation-based representation, intent-driven representation treats a design as an evolving cognitive process that can be reflected by the evolution of design intents. Current intent-driven representation models represent design intents explicitly, and a design history can be captured by preserving design intents and their evolving tracks. Ganeshan et al. (Reference Ganeshan, Garrett and Finger1994) proposed a model to represent design intents in which design intents are defined and evaluated as the design process evolves. In the design intent modeling system implemented by Arai et al. (Reference Arai, Okada and Iwata1992), a design process is described by intents, operations, and design flows. An evolving DR driven by the interaction between design intent and design operation can be represented using this approach. The design intent model can also be integrated with product models. A design process language is introduced to record the history of design processes (Arai et al., Reference Arai, Shirase and Wakamatsu1998). However, this approach has some disadvantages. First, although the design process language can reflect the problem finding or understanding process by describing the coevolving process of design intent and design operations, it does not refer to other DR elements, such as other design options considered, justifications for design decisions, trade-offs, and evaluation criteria. Second, it fails to capture the design situational information. The situational information can be summarized as “where you are, when you do, or what you do matters” (Gero & Kannengiesser, Reference Gero and Kannengiesser2004), considering the external environment where the design is executed, such as time constraints and special conditions. The situational information is also critical to the design process because it can interact with and further influence design intents and design operations. Recording corresponding situational information can effectively help us understand why the design is made the way it is. Therefore, the conventional intent-driven representation cannot represent DR completely.

More and more researchers today realize that the DR model based on evolving intents can reflect the cognitive characteristics of a design process more accurately than more traditional approaches. Design intent has become a focus of research. The main research includes how to capture design intents from computer-aided design models (Kim et al., Reference Kim, Pratt, Iyer and Sriram2008; Li et al., Reference Li, Langbein and Martin2010) and how to represent design intent (Liu & Sun, Reference Liu and Sun2008). However, no systematic theory or method has emerged to improve the research on intent-driven DR representation. No representation model that can reflect the design situation, design cognition, design operation, and design evolution process has been constructed.

3.1. DR elements

The proposed representation model consists of four submodels: design intent, design decision, design justification, and design operation, as shown in its knowledge structure (Fig. 1). The design process involves a designer's internal thinking and outside world, that is, the product world. The internal world processes information from the product world and in turn makes changes to the product world through design activities. The DR model represents the internal world of a designer, whereas the product world reflects DR in the actual world by describing actual entities of the product (i.e., its function, behavior, and structure). Design operation is shared by the DR model and the product world in the proposed representation. It acts as a bridge between the two worlds. The information on corresponding artifacts can be linked to the DR model by attached documents, hyperlinks, and so on. A detailed description of the DR elements follows.

Fig. 1. The knowledge structure of the design rationale mode.

3.1.1. Design intent

Design intent is the core of the proposed DR model. It is the initiation and motivation of a design process, generally representing what a designer wants to do. Ullman (Reference Ullman2002) cited a definition of design intent: “During product design, the intent is the blueprint for the evolution of the requirements into the production specification. This blueprint not only has information about the development of the geometry, but also on the evolution of the product function and behavior, the rationale underlying design decisions and the influence of business activities.” Therefore, design intent is not just a design goal or a design problem. It contains different kinds of information.

According to the different roles it plays in the design process, design intent is classified into six categories: formulation intent, generation intent, evaluation intent, synthesis intent, plan intent, and communication intent. Different categories have different characteristics. Formulation intent decides what to do to formulate a complete design problem. It concerns the formulation process of the design problem structure. As a design process is proceeding, a design intent is derived when the design specification is explicit. Formulation intent is embodied by the “design intents” proposed in the DR model and their decomposition process. Generation intent guides designers to propose design options or decisions that can satisfy the design requirements or resolve the current design task. Evaluation intent instructs designers to compare the proposed design options against some design criteria to come to a decision or it refines the current decision to fit changed design requirements or conditions. If the proposed options cannot satisfy the requirements, designers use synthesis intent to analyze the design options, decisions, and related evidence synthetically in order to obtain a more complete solution. Planning intent decides appropriate design directions where a design needs iteration or modification, such as which intent, option, evidence, or decision should be modified or replaced. Planning intent directs the progress of the design process. With communication intent designers exchange design methods or design results with the external environment or other cooperative partners. Different categories of design intent exist that underlie design activities during a design process. They are implicit but reflected by the contents of the whole DR model.

In the representation model, a design intent can be generated, evaluated, modified, and even eliminated during the design. It can also be decomposed into several subintents (sI), which can be decomposed continually. Dependency relationships among different design intents can be represented by a design intent tree (Fig. 2). The root node of the design intent tree is an initial intent. Elementary intent (eI) is defined as the minimal unit of the design intent that cannot be decomposed further.

Fig. 2. The design intent tree.

3.2. Relationships of DR elements

The proposed representation model defines seven types of basic semantic relationships among DR elements. DR elements and their relationships are shown in Figure 2 and Figure 3 and detailed in the following:

1. 1. Decomposed-into<intent, intents> is the relationship between an intent (I1) and two or more intents (I2, I3) whereby I1 can be achieved only when I2 and I3 are achieved.

2. 2. Achieved-by<intent, option> means that the option is an alternative proposed to achieve the design intent.

3. 3. Decided-by<option/options, decision> means that the option is selected or several options are synthesized by a designer to be the final decision.

4. 4. Realized-by<decision, operation> is the relationship between decision and operation, meaning that the operation turns the decision into actual activities.

5. 5. Follows<option, evidence> is a relationship that means the option is proposed by conforming to the evidence.

6. 6. Refers-to<decision, criterion/tradeoff> relates a decision to the criterion or trade-off that it refers to for decision making.

7. 7. Initiates<operation, intent> is the relationship that relates an operation to an intent, meaning that the result of the operation will initiate a new intent.

Fig. 3. (Color online) The design rationale elements and their relationships.

Taking part of the design process of a gear set as an example, Figure 3 demonstrates the relationships of DR elements. At the beginning of the design, the diameter and breadth of the small gear are proposed in design option O1. O1 follows evidences E1 and E2. During the later design process, after the fatigue strength of the gear tooth surface contact is checked, O1 is reevaluated and the designer finds that O1 is not a suitable option. Then, D1 is made referring to C1 and T1 to increase the diameter of the small gear, namely, the small gear should be redesigned. A new option O2 is proposed and decision D2 is made. Finally, D2 is realized by Op1, and Op1 initiates design intent I2.

3.3. Knowledge representation of DR

Formalizing the DR representation in a consistent manner can improve the expressiveness of the DR model and further help designers easily capture, manage, understand, and reuse the DR. A set of representation rules should be constructed, and the ontology can be employed to fulfill the DR formalization. Ontology provides a semantics-based approach to structure the concepts and their relationships within a given domain. It can be seen as a realization as well as a practical argument for knowledge-based processing (Nirenburg & Raskin, Reference Nirenburg and Raskin2003). In this paper, a preliminary OWL-based knowledge representation is developed to formalize the DR. OWL is a common ontology language for the Semantic Web, developed by the World Wide Web Consortium Web Ontology Working Group. It was primarily devised to represent knowledge (i.e., objects and how objects are interrelated) to be shared and exchanged without disputes as to precise meaning. The OWL-based knowledge representation can be understood and reasoned by computer, which can further improve the computability of the DR model.

In the DR representation, the class and object property in OWL can be employed to represent DR elements and their relationships as mentioned above. Taking the design intent as an example, its expression in OWL is detailed below.

Design_intent has four kinds of attributes: Intent_ID, Intent_name, Intent_description, and Intent_state, which can be represented by the relationships hasIntentID, hasIntentname, hasIntentdescription, and hasIntentstate, respectively. In the proposed DR model, an intent has one and only one Intent_ID, which can be guaranteed by the OWL restriction: owl: qualifiedCardinality. An intent can exist in one of three states: satisfied, unsatisfied, or unconsidered. This can be represented by an OWL enumerated class that is implemented by owl: oneOf. The OWL-based representation of design intent is partially shown in Figure 4.

Fig. 4. The knowledge representation of design rationale.

Likewise, other DR elements have their specified subclasses and attributes, which can be represented in a similar way. The relationships between different DR elements and the reasoning rules can also be defined in OWL format.

4.1. Definition

Tang and Frazer (Reference Tang and Frazer2001) define a context as a series of design actions initiated by an individual designer or design team. It is regarded as an isolated design environment in which a design action cannot affect other designers’ work in a collaborative design. In this paper the design context is defined as a logical assembly of elements in the DR model that can satisfy the initial intent. It is addressed below.

Figure 5 shows one of the episodes of the iterative design cycle. The DR model is a complex chain of a design cycle, consisting of a series of design episodes to capture the complete and evolving design process. Although designers need to review the whole design process sometimes, more often they need to access certain parts of the process regarding certain DR elements. Dealing with the whole process and looking up specific answers are time-consuming and difficult. Breaking the DR model into episodes can reduce the complexity of the model. An episode starts when a primary intent is generated and ends when decisions have been made or operations have been undertaken to satisfy the intent. For example, Figure 5 shows an episode around I1.

Fig. 5. An example of a design episode.

In this episode, there are two kinds of logical relationship among its elements: and and or (Fig. 5). If the relationship among the elements is and, all of them must be satisfied simultaneously to satisfy the initial intent of the episode. If the relationship is or, only one of them needs to be chosen. The dependency relationship of the episode decides that there can be several assemblies of elements that can achieve the intent.

In one episode, there may be more than one design context. For example, a context of the episode in Figure 5 is outlined with dashed and curved shapes in Figure 6a. Based on the dependency relationship of elements, Figure 6b represents another context of the episode when O2 is taken as a decision. Based on the logical relationship among DR elements, the design context can further reduce the complexity of the design episode.

Fig. 6. A context analysis.

4.2. Organizing DR with context

Again, taking the gear set design in Figure 3 as an example, when O1 cannot satisfy I1, designers have to redesign and propose O2. This is an iterative process in which O1 evolves into O2 and D1 evolves to D2. Figure 3 sequentially documents the DR according to the design activity, but its iterative and evolving process cannot be represented clearly. The context of the DR can be employed to document the complete DR and its evolving history. Two kinds of relationships of DR elements are added to the DR model:

1. 1. Return-to< , >: Return-to highlights the start and the end of an iterative process in the DR when a designer returns to modify previous DR elements. It consists of return-to<operation, intent/option/decision>, return-to<decision, intent/option/decision>, and return-to<intent, intent/option/decision>.

2. 2. Evolve-to< , >: Evolve-to reflects the modification and evolution of design intent, option, and decision during the design process that is attributable to underlying reasons such as the occurrence of design mistakes, acquisition of new knowledge, and a change of situational information. It consists of evolve-to<intent, intent>, evolve-to<option, option>, and evolve-to<decision, decision>.

The relationships Return-to< , > and Evolve-to< , > retain a complete and clear design and decision history that documents how and why a design has evolved. As shown in Figure 7, Return-to represents what D1 the designer returns to redesign the diameter of the small gear. Then, another DR context is added as shown with the dashed box, O2 is proposed, and D2 is made. Evolve-to represents the evolution track of O2 and D2. Associated reasons for the evolving decisions are explicitly documented in terms of evidence, criteria, and trade-offs. Similarly, I1 can evolve into another intent and D2 can evolve into another decision when it is needed.

Fig. 7. (Color online) The context of the gear set design.

Therefore, the explicit representation of the design context can offer a number of advantages in capturing the evolving DR completely and clearly, which might otherwise be unattainable.

First, the design context enables a complete documentation of the DR and its evolving history. It can represent different assumptions about the design episode, such as selecting different options, referring to different criteria or evidences, even choosing different intents to achieve, as shown in Figure 6. Thus, it allows a designer to explore and retain different routes of a design process because the change of elements in a context cannot influence elements in other contexts, even if they share the same intent. When the designer has a new idea, plausible modifications to a part of an episode can be made by creating a new context to observe the influence without necessarily losing any previous DR information, such as adding a branch to a branching tree. The branch inherits the design decisions made in its parent design branch. Furthermore, the reason or justification for the modification can be documented in the new context, and the context of the DR provides an explanatory power to the DR model for evolutionary steps of DR elements.

Second, the context can provide a designer with complete DR knowledge when he or she wants to understand, modify, or reuse a previous design. This can be achieved through three different kinds of trace schema:

1. 1. Forward trace: The purpose of this trace is to support an impact analysis of a design. Given an element in the DR model, all dependent elements downwardly caused and influenced by the given element can be traced. This trace can help designers identify which element would be affected when the given element is modified.

2. 2. Backward trace: The purpose of this trace is to support a root-cause analysis of a design. For a given element, all other elements it directly or indirectly depends on can be traced. This enables designers to understand and analyze elements leading to the given element.

3. 3. Evolution trace: The purpose of this trace is to support an analysis of an evolving DR element. Given an element, the history containing previous versions of it with the cause of the evolution can be retrieved through the relationship evolve-to. This provides designers with a thorough understanding of the design's evolving history.

Therefore, the context of DR not only helps capture and manage the complete DR but also serves a designer with corresponding information effectively and efficiently. Furthermore, OWL-based knowledge representation of the DR enables the context to be understood and reasoned via computer. Some existing rule engines, such as Jess, can be employed to implement the actual tracing task. Jess (Friedman-Hill, Reference Friedman-Hill2003) is one of the widely used light-weight rule engines for the Java platform. It provides an improved Rete algorithm to support reasoning.

5.1. Graphical interface

Given the knowledge representation of the DR, it would be a difficult task for designers to learn and record the DR in OWL format manually. A graphical modeling interface is proposed to help designers input the DR. The tool provides graphical symbols for representing the elements and relationships. A designer can express his/her design process simply by dragging corresponding symbols from the toolbox on the upper part of the interface to the modeling region below the toolbox and then linking them. When the designer adds a new DR element or a new relationship between two elements and right-clicks on the item, a dialog box will be pushed out by the system, asking the designer to input the name, status, description, and all other attributes of the item. The system can simultaneously save the DR information in OWL format. When the designer selects one constructed node or relation and left-clicks on it, the property column on the lower left part of the interface can present all of its attributes. On the upper left part of the interface is the hierarchy of the DR. When the designer selects one of the episodes, the tree structure of the selected episode will be unfolded. At the same time, the elements and their relationships in this episode will be presented as nodes and links in the graphical modeling region. Therefore, the graphical modeling will be much more helpful to a novice designer if he/she is unfamiliar with the syntax.

Part of the design process of the bending die is presented in this paper. The main process involves the following steps. The details about the DR elements are explained in Table 1.

1. 1. With the formulation intent, the initial intent can be decomposed into three subintents: sI1 is to design the rebound measuring device, sI2 is to design the upper part of the bending die, and sI3 is to design the lower part of the bending die.

2. 2. With an aim to sI1, four episodes are processed. With the formulation intent, sI1 is decomposed into two eIs: eI11 and eI12.

Table 1. Explanation for the example

In episode 1 surrounding eI11, to select the measuring method with the generation intent, two options O1 and O2 are proposed with their evidences E1 and E2, respectively. Then, with the evaluation intent, the designer evaluates the options against criteria C1, C2, C3, and C4. Decision D1 is made.

In episode 2 surrounding eI12, to identify the measuring method with the generation intent, two options O3 and O4 are proposed with their evidence. With the evaluation intent, the designer evaluates the options against criteria C4 and C5. Decision D2 is made. However, in the later design stage, the designer finds that C2 is the most important criterion and should be considered prior to C4 and C5. Therefore, with the planning intent and synthesis intent, the designer returns to D2 to redesign the measuring method in episode 3 and changes the decision. D2 evolves into D3 with its justification. The names of episodes 2 and 3 are the same in Table 1 because they are iterative processes to satisfy the same intent: “identify the measuring method.”

After D1 and D3 are made, eI13 is formed in episode 4 to design the placement space for the measuring tool. As with the other episodes, the options are proposed and evaluated to make the decision.

After episode 4, an operation is performed to draw the schematic of the rebound measuring device. Then, a new design intent is initiated in episode 5 to further satisfy sI1. The DR can be recorded as demonstrated in Figure 10, and the associated knowledge representation in OWL format is saved by the system.

Fig. 10. The graphical modeling interface.

5.2. Context manager

Based on the description logic of DR knowledge representation, designers can create, modify, and maintain contexts of the DR with the context manager provided by the system. Moreover, the system allows designers to define the start point, reasoning direction, and reasoning depth to retrieve related DR elements. For example, when the designer of the bending die wants to modify the previous decision, he prefers to select O4 rather than O3, according to his justification against the evidence, criteria, or trade-offs; the context manager can help him understand the initial design by providing him with the root cause of D2, downward design process that may be influenced, and different versions of D2 in the design history, if any. Furthermore, the designer can create his design process by constructing a new context in the context manager. For example, the designer can make decision D3 without losing previous versions of D2. Figure 11 shows the evolution trace of D3, explaining why D2 is evolving into D3.

Fig. 11. The context manager.

In addition, in each trace scheme, the context can also support classification-based traceability. The designer can limit the trace results to the specified types of DR elements. For example, a trace could traverse only those options proposed for a given intent. Classification-based traceability can reduce information overload when the designer is analyzing trace results.

5.3. Attached document

Designers can upload and annotate related documents of the DR, and the uploaded documents will display when a designer clicks on the relevant node. As is shown in Figure 12, the schematic of the rebound-measuring device can be attached as the reference of eI14.

Fig. 12. A schematic of the rebound measuring device.

Therefore, the system can capture, formalize, and manage the evolving DR knowledge in an effective way. It supports designers to record their complete thinking processes and to review, understand, and reuse previous DR knowledge conveniently. It can also ensure that the input DR is grammatically correct in every step of the DR record by pointing out any syntactic or semantic errors.