1. INTRODUCTION
Teleological modeling is fundamental to understanding and explaining many complex systems, especially engineered systems. By complex system, we mean a system that not only has many interconnected components but also has causal processes at multiple levels of abstraction such that a causal process at one level emerges out of component interactions at a lower level. By teleological model of a system, we mean a representation that specifies both the functions of the system and the causal processes that result in the system functions. It follows that a teleological model of a complex system would specify the system functions and the causal processes that result in them, at multiple abstraction levels.
Of course, teleological models are not necessarily useful for understanding or explaining all artifacts. We may view artifacts as lying on a spectrum of teleological explanation. At one end of this spectrum are artifacts for which teleological explanations are very useful. For example, the door system in my office has a useful teleological explanation: its functions (closing and opening) are accomplished by causal processes (pushing or pulling on the handle of the door, which creates a torque about the hinges that connect the door to the wall, which generates an angular motion about the hinges, and so on). Although the physical structure of the door (e.g., its connection to the wall) both affords and constrains its motion, its causal processes mediate between its structure and its functions. At the other extreme of the teleological spectrum are artifacts whose function directly emerges from the shape of its structural components. For example, the function of the desk on which my computer sits (providing a flat space for placing objects) directly emerges from the shape of its structure (a large flat top) without any mediation by a causal process. Many artifacts lie in the middle of this teleological spectrum, containing some subsystems that are teleological and others that are not. For example, the function of the chair that I am sitting on while I type these words directly emerges from the shape of its structure. In contrast, the chair also contains a lever so that when I push the lever down, it lowers the height of the seat; this function is accomplished by a causal process. In this paper, we are concerned solely with the ontology of complex systems in which causal processes mediate between their structure and functions.
Computational research on engineering design and problem solving has led to several ontologies for teleological modeling such as functional representation (Sembugamoorthy & Chandrasekaran, Reference Sembugamoorthy, Chandrasekaran, Kolodner and Riesbeck1986; Chandrasekaran, Reference Chandrasekaran1994; Chandrasekaran & Josephson, Reference Chandrasekaran and Josephson2000), function–behavior–structure (FBS; Gero, Reference Gero1990; Gero et al., Reference Gero, Tham, Lee, Brown, Waldron and Yoshikawa1992), and function–behavior–state (Umeda et al., Reference Umeda, Takeda, Tomiyama and Yoshikawa1990, Reference Umeda, Ishii, Yoshioka, Shimomura and Tomiyama1996; Umeda & Tomiyama, Reference Umeda and Tomiyama1997). By ontology, we mean a vocabulary of knowledge representation (cf. Bunge, Reference Bunge1977), who views ontology as pertaining to the nature of the world). The structure–behavior–function (SBF) knowledge representation language (Bhatta & Goel, Reference Bhatta and Goel1994, Reference Bhatta and Goel1997; Goel et al., Reference Goel, Gomez, Grue, Murdock, Recker and Govindaraj1996; Prabhakar & Goel, Reference Prabhakar and Goel1998; Goel & Bhatta, Reference Goel and Bhatta2004) provides one such ontology for teleological modeling.
Although SBF modeling is fairly mature by now (as is indicated by the years of publication in the list of references), recently our work has explored computational tools for interactive construction of SBF models, which raises several new research issues. The design literature typically described ontologies for teleological modeling only at a high level, often using teleological models of specific systems as illustrations. This is because a high-level specification of the ontology often is sufficient to explain a computational theory or model. However, a high-level specification of our SBF ontology is inadequate for developing an interactive tool for constructing an SBF model. This is because model building is an open-ended task, and the higher the level of specification of the ontology the less constrained the task becomes and the less guided is the human user. Users may potentially use the interactive tool to construct a variety of SBF models in a variety of ways, many of which might be incorrect or incomplete. Furthermore, the tool may need to incorporate model checking functionality to provide feedback to the users about the correctness of their models, creating a need for more precise specification of the ontology. Thus, for the purpose of developing an interactive tool, we need to view SBF as a programming language with a well-defined syntax and semantics. An SBF language would both constrain the actions of a user as well as afford the construction of useful SBF models. The language would also enable automated model checking. In addition, it would enable the construction of agents that both guide a user in constructing an SBF model as well as critique a constructed model. The primary goal of this paper is to specify the abstract syntax of the SBF language and to describe how the static semantics of the syntax enables interactive construction of SBF models.
2. AN ILLUSTRATIVE EXAMPLE OF SBF MODELS
To motivate the SBF programming language, let us consider a simple example: teleological modeling of a gyroscope follow-up, a device used in gyrocompasses on ships. (Briefly, the gyrocompass, with its ability to track true north compared to the unreliable magnetic north, is an instrument for navigation and piloting aboard many ships.) A gyroscope is an assembly with a very rapidly spinning top. A gyroscope follow-up automatically tracks and amplifies the movement of a spinning gyro. The follow-up servo can drive any number of gyrocompasses located anywhere on a ship, each of which replicates the reading of the central gyro. Figure 1 illustrates the structure of a simple gyroscope follow-up with no feedback control.
A schematic diagram of the gyroscope follow-up.
2.1. Structure
In SBF models, structure is represented in terms of components, the substances contained in the components, and connections among the components. The specification of a component includes its functional abstractions, where a component can have multiple such functions. The specification of a substance includes its properties. Substances can be abstract, as, for example, angular momentum.
2.2. Function
A function is represented as a schema that specifies its preconditions and its postconditions. The function schema contains a reference to the behavior that accomplishes the function. This schema also may specify conditions under which the specified behavior achieves the given function (e.g., an external stimulus). Figure 2 illustrates the schema for the function of the gyroscope follow-up of Figure 1. Informally, the function specifies that the device takes as input angular momentum of magnitude L i and of clockwise direction at the input (gyroscope) location and produces a proportional angular momentum of magnitude L o and of clockwise direction at the output shaft location; L o fluctuates over a large range, that is, L o = L avg ± Δ, where Δ can be large.
A representation of function.
2.3. Behavior
A behavior is represented as a sequence of states and transitions between them. The states and the transitions are represented as state and transition schemas, respectively. The states in a behavior specify the evolution in the values of the parameters of substances and/or components. Continuous state variables are discretized, and temporal ordering is subsumed by causal ordering. Each state transition in a behavior is annotated by the causes for the transition. Causal explanations for state transitions may include physical laws, mathematical equations, functions of its subsystems, structural constraints, other behaviors, or a state or transition in another behavior. Figure 3 shows the behavior that explains how angular momentum from the input gyroscope location is transferred to the output shaft location. The functional context specified by the annotation
in Transition 3–4 indicates that the transition occurs because of the primitive function “
Angular Momentum” of Hydraulic-Motor.
A representation of behavior.
3. BACKGROUND OF SBF MODELS
Before we go further, we need to situate SBF modeling in the context of teleological modeling of complex systems in general. In Sciences of the Artificial, Simon (Reference Simon1996) viewed a system as having an inner and an outer environment. Further, he viewed a function of the system as an abstraction of its inner environment, lying at the interface of its inner and outer environments. Simon suggested that, from the perspective of understanding design of complex systems, the right kind of explanations specified how the function of a system arises out of the components and processes in the inner environment of the system.
In the early 1980s, Chandrasekaran and associates developed a functional representation (FR) scheme for representing teleology (Sembugamoorthy & Chandrasekaran, Reference Sembugamoorthy, Chandrasekaran, Kolodner and Riesbeck1986; Chandrasekaran, Reference Chandrasekaran1994). They used the FR representation of a system for explanation and diagnosis. The FR representation of a system explains how its causal processes accomplish its functions and how the causal processes hierarchically compose the functions of the system's components into the functions of the systems as a whole. Thus, FR not only represented the functions of a system explicitly, but also used the functions as indices into the causal processes (called behaviors) that accomplished the functions; the behaviors, in turn, indexed the functions of the subsystems, and so on. At about the same time, Rasmussen developed an SBF scheme for representing teleology (Rasmussen, Reference Rasmussen1985; Rasmussen et al., Reference Rasmussen, Pejterson and Goodstein1994). Rasmussen and colleagues used the SBF representations of very large complex systems, such as an electrical power plant, to interactively aid human operators in troubleshooting the system. Their SBF representations emphasized representation of the functional roles of the structural components of the system.
In the late 1980s, Gero et al. (Gero, Reference Gero1990; Gero et al., Reference Gero, Tham, Lee, Brown, Waldron and Yoshikawa1992) and Tomiyama et al. (Umeda et al., Reference Umeda, Takeda, Tomiyama and Yoshikawa1990, Reference Umeda, Ishii, Yoshioka, Shimomura and Tomiyama1996; Umeda & Tomiyama, Reference Umeda and Tomiyama1997) independently developed FBS schemes for representing teleology. (Tomiyama sometimes calls his representation scheme the FBS model.) Gero and Tomiyama used their respective FBS schemes for understanding the process of designing engineered systems and for aiding human designers in the design process. In the 1990s, Chakrabarti and Bligh (Reference Chakrabarti and Bligh1996), Stone and Wood (Reference Stone and Wood2000), and Mizoguchi and his colleagues (Sasajima et al., Reference Sasajima, Kitamura, Ikeda and Mizoguchi1995; Kitamura et al., Reference Kitamura, Kashiwase, Fuse and Mizoguchi2004), among others, developed similar functional representation schemes and for similar uses. It is important to note that, as a consequence, there is not one but several functional representation schemes currently in the field. Although the various functional representation schemes have many features in common, their ontologies often are quite different. For example, behavior in Chandrasekaran's FR scheme refers to a causal process, whereas behavior in Gero's FBS representation pertains to the properties of a structural component. Erden et. al (Reference Erden, Komoto, van Beek, D'Amelio, Echavarria and Tomiyama2008) provide a recent useful review of several major functional representation schemes.
The origin of our SBF representation of teleology (Bhatta & Goel, Reference Bhatta and Goel1994, Reference Bhatta and Goel1997; Goel et al., Reference Goel, Gomez, Grue, Murdock, Recker and Govindaraj1996; Prabhakar & Goel, Reference Prabhakar and Goel1998; Goel & Bhatta, Reference Goel and Bhatta2004) lies in Chandrasekaran's FR scheme (e.g., Goel & Chandrasekaran, Reference Goel and Chandrasekaran1989; Chandrasekaran et al., Reference Chandrasekaran, Goel and Iwasaki1993). In particular, our SBF models both combine FR with Bylander's component–substance ontology and primitive functions (Bylander, Reference Bylander1991) and extend FR to support the inferences needed for automated design (Goel & Chandrasekaran Reference Goel and Chandrasekaran1989, Reference Goel, Chandrasekaran, Tong and Sriram1992; Goel, Reference Goel, Brown, Waldron and Yoshikawa1992; Goel et al., Reference Goel, Bhatta, Stroulia, Maher and Pu1997). SBF models share the main features of the FR scheme:
1. functions of devices are represented explicitly;
2. functions act as indices into internal causal behaviors responsible for them;
3. behaviors are represented as an ordered sequence of states;
4. state transitions in a behavior are annotated by the causal explanations for them;
5. the causal explanations can be of several types, for example, component function, structural relation, domain principle, and another behavior; and
6. the component function explanations for transitions act as indices into functions at the next (lower) level of aggregation.
SBF models also extend the FR scheme:
1. SBF models use a component–substance ontology of devices, which enables a more precise specification of states in a behavior or in a function;
2. SBF models use an ontology of primitive functions based on the component–substance ontology, which enables a more precise specification of state transitions in a behavior;
3. in SBF models, separate behaviors are constructed for substances and components, which makes for a more precise specification of behaviors as a whole;
4. the functions of systems are viewed as the intended subset of its output behaviors, and SBF models allow specification of all output behaviors of a device;
5. the internal causal behaviors in an SBF model may branch and merge; and
6. the internal causal behaviors admit inverse causality and bidirectional causality.
Although (4), (5), and (6) above enhance the expressive power of FR, (1), (2), and (4) afford more precise and accurate inferences needed for automated case-based design.
We have used SBF models in several design systems as briefly described below in Section 5. In addition, the functional representations in the NIST design repository (Szykman, Racz, et al., Reference Szykman, Racz, Bochenek and Sriram2000; Szykman, Sriram, et al., Reference Szykman, Sriram, Bochenek, Racz and Senfaute2000) have much in common with SBF models. Anthony et al. (Reference Anthony, Regli, John and Lombeyda2001) have developed a mark-up tool for interactive labeling of three-dimensional computer-aided design (CAD) models by structures, behaviors, and functions.
4. ABSTRACT SYNTAX OF THE SBF LANGUAGE
This section presents a top-down, syntax-oriented grammatical description of SBF. The notation used is a variant of Backus–Naur Form (BNF; International Organization for Standardization, 1996) in which syntactic definitions are described using production rules in which the term being defined appears on the left of a separator (
), and its definition appears on the right as a sequence of terminal and nonterminal symbols. Terminal symbols denote categories of atomic words in an SBF model. Important categories in SBF are
and
. A specific literal string may also appear in the grammar between straight apostrophes as in “
.” Other textual names denote nonterminal units that are defined in other rules in the grammar.
Several operators are used in the syntactic definitions. Juxtaposition denotes concatenation; “
” denotes alternative; “
” denotes optionality, where
is any string of symbols; “
” and “
” denote, respectively, any number of occurrences of
and any nonzero number of occurrences. Finally, “
” denotes a comment that proceeds from the slashes to the end of the line.
Together, the following set of rules comprises an abstract syntax for SBF. The syntactic description is abstract because it avoids concrete details such as punctuation and keywords.
4.1. SBF model
At the highest level, an SBF specification looks like the following:
That is, an SBF specification comprises six parts, appearing consecutively: a name, an optional description, specific submodels for structure, function, and behavior, and one or more external stimuli to which the system being modeled might react. These latter four constituents are now described in corresponding subsections.
4.2. Structure model
A StructureModel is merely one or more
and the
among them.
An
consists of a unique identifier followed by a name, an optional description, and a list of
. An
is either a physical
or a
. Moreover, an
can itself have subcomponents, leading to a hierarchical structural breakdown. Several comments are in order. First,
s, like many other of the nonterminals to be described below, have unique identifiers. This enables dependencies among the Structure, Behavior, and Function submodels to be described. Second,
are used throughout SBF models to denote named, typed values. Here is the syntactic definition of a Property.
have
in the sense of belong to a set of related values, such as
or
. Moreover, because SBF models physical devices, it supports the use of scientific
to further describe the
. The nonterminal
is intended to enable the modeler to indicate that the
of a particular
is not subject to change.
are
that can be connected with other
. They should be distinguished from
, which are used to model fluids and forces.
are binary, associating named
in
. Moreover,
are partitioned into categories based on the way in which force is transferred between the corresponding
.
4.3. Behavior model
Behavior is modeled in SBF with deterministic finite state machines. In fact, a
is nothing more than a set of
and related
.
constrain the values of
at
.
are directed binary associations between
. Moreover, each
might have a number of
motivating the change of
.
4.4. Function model
in SBF describe the role that an
plays in the overall operation of a device. They express the purpose or goal of the
, whereas the
describes how the purpose is accomplished. Each
in an
has a
, and each
has a corresponding
.
The SBF ontology comprises a number of primitive
useful for describing devices. Moreover, modelers can define new (
) ones.
The SBF ontology also distinguishes categories of
, partitioned according to how the corresponding
affects the
.
4.5. Stimuli
The final constituent of an
describes the environmental
that can affect its
.
A
may have an associated
, describing its amplitude.
5. STATIC SEMANTICS OF THE SBF SPECIFICATION LANGUAGE
The abstract syntax given above is useful for describing the appearance of SBF models, but not how to interpret them. In particular, some syntactically correct models may be incomplete or have inconsistencies. Here we present a series of rules that distinguish valid from invalid
.
5.1. Uniqueness constraints
The first category of rules merely specifies that the identifiers used to label different model constituents are themselves different; for example, each
in
is unique. Additional rules in this category include the following:
• There is only one (directed)
Transitionbetween any twoStatesin the sameBehavior.• No two
CausalExplanationson anyTransitionmay be the same.• No
NonPrimitive-Function Namecan be the same as anyPrimitive-Function Name.• For any given
Connection, theFirstConnectingPointIdmust differ from theSecondConnectingPointId.
5.2. Referential integrity constraints
Another category of model rules has to do with referential integrity. This term refers to situations in which an identifier in one place in a model refers to (is identical with) an identifier in another place. In general, there should be no missing targets to any reference.
• Each
StartStateIdandStopStateIdinFunctioncorrespond to actualStatesexisting in theBehaviorreferred to byBehaviorIdin that sameFunction.• Each
ElementIdinContentrefers to aComponentthat has aFunctionwith theBehaviorcontaining theStatethat has thatContent.• Each
ConnectingPointIdinContentrefers to aConnectingPointin aComponentthat has aFunctionwith theBehaviorcontaining theStatethat has thatContent.• Each
SourceStateIdandTargetStateIdinTransitionrefers toStatesthat exist in theBehaviorcontaining theTransition.
5.3. Organizational rules
Several other rules are necessary to further constrain valid SBFModels.
• A
StructureModelcontains exactly oneElementthat is not referred to by aSubElementId. ThatElementmust be aComponentand not aSubstance. That is, the device itself being modeled is considered as the outermostElement.• Each
SubElementIdin anyElementrefers only to anElementbelow itself in the containment hierarchy. That is, theElementcontainment hierarchy is a strict tree structure.• Each
FunctionIdin theCausalExplanationof aTransitionin aBehaviorcorresponds to aFunctionthat does not have that Behavior.• Each
StateIdreferred to in aCausalExplanationof aTransitionin aBehaviorcorresponds to aStatein a differentBehavior.• Each
TransitionIdreferred to in aCausalExplanationof aTransitionin aBehaviorcorresponds to aTransitionin a differentBehavior.
6. DYNAMIC SEMANTICS OF THE SBF SPECIFICATION LANGUAGE
SBF models of complex systems enable computer programs to draw inferences about the systems. The inference rules for a particular program provide an interpretation of an SBF model. The set of allowed interpretations for a program provide a specific dynamic semantics to the SBF language. Here are several examples.
6.1. Kritik
Kritik (Goel & Chandrasekaran Reference Goel and Chandrasekaran1989, Reference Goel, Chandrasekaran, Tong and Sriram1992; Goel, Reference Goel, Brown, Waldron and Yoshikawa1992; Goel et al., Reference Goel, Bhatta, Stroulia, Maher and Pu1997) was an early automated design system that integrated case-based and model-based reasoning for generating conceptual designs of simple engineering devices. It indexed known designs by their functions and used SBF models of the known designs to guide the process of design adaptation. Given the functional specification of a new problem, Kritik retrieved designs that delivered similar functions, viewed a retrieved design as having failed to achieve the given desired function, and used the SBF model of the design to diagnose the causes for the failure and propose modifications to the design. Thus, the SBF models in Kritik enabled both design retrieval and design adaptation.
6.2. Ideal
Ideal (Bhatta & Goel, Reference Bhatta and Goel1994, Reference Bhatta and Goel1997; Goel & Bhatta, Reference Goel and Bhatta2004) was an early automated design system that used cross-domain analogies for generating designs of simple engineering systems. Like Kritik, it indexed known designs by their functions and used SBF models of known designs to guide the process of design adaptation. In addition, it used behavior–function (BF) representations of abstract teleological mechanisms (such as “feedback”) for cross-domain transfer. Given the functional specification of a new problem, Ideal retrieved a design that delivered a similar function, viewed the retrieved design as having failed to achieve the given desired function, used the SBF model of the design to diagnose the causes for the failure, and proposed modifications to the design. If and when this adaptation process failed, however, Ideal abstracted the functional specification of the problem, retrieved an abstract teleological solution relevant to the abstract functional problem, and instantiated the mechanism in the context of the design retrieved earlier. It also learned abstract teleological mechanisms from SBF models of known designs, Thus, SBF models in Ideal enabled abstraction, transfer, and instantiation of abstract teleological mechanisms.
6.3. Torque
Torque (Griffith et al., Reference Griffith, Nersessian and Goel2000) modeled verbal protocols (Clement, Reference Clement, Glover, Ronning and Reynolds1989) of physicists addressing problems pertaining to spring systems. In Torque, retrieval of an analog was based on structural similarity instead of functional similarity. The SBF model of the retrieved analog enabled the transfer of qualitative mathematical knowledge across domains (from the domain of bending beams to that of spring systems).
6.4. Archytas
Archytas (Yaner & Goel, Reference Yaner and Goel2007, Reference Yaner and Goel2008) is a recent automated system that constructs SBF models from design drawings by analogical transfer of SBF models of similar drawings. Given a target design drawing, and given also a known design drawing and its SBF model, Archytas maps, transfers, and adapts the SBF model of the known drawing to the target drawing. To do this, Archytas extends SBF models into DSSBF models (for drawing–shape–structure–behavior–function), thereby incorporating shapes and drawings into SBF models. In Archytas, analogical mappings at one level of abstraction (e.g., shape) enable transfer at the next higher level (e.g., structure).
7. FROM AUTOMATED SYSTEMS TO INTERACTIVE ENVIRONMENTS
Kritik, Ideal, Torque, and Archytas are automated systems. InteractiveKritik (Goel et al., Reference Goel, Gomez, Grue, Murdock, Recker and Govindaraj1996; Goel & Murdock, Reference Goel, Murdock, Smith and Faltings1996) enabled a human to browse the designs in Kritik's design library, the SBF models of the designs Kritik generated, and Kritik's processing in generating a design. InteractiveKritik, however, did not allow the user to interactively construct SBF models.
Interactive model construction environments provide external representations, which can be powerful tools to support designing and learning. Clement (Reference Clement2000) has argued that learning is fundamentally a process of model construction and revision. Buckley (Reference Buckley2000) has shown that interactive environments can help students learn about models of complex systems at multiple levels of organization. Hmelo-Silver et al. (Reference Hmelo, Holton and Kolodner2000) have suggested that although experts model a complex system in terms of its interrelated structure, behaviors, and functions, novices primarily express its structure, demonstrate limited understanding of its functions, and largely miss its behaviors. Hmelo-Silver and Pfeffer (Reference Hmelo-Silver and Pfeffer2004) have recommended use of interactive environments that enable construction of SBF models to support learning about complex systems. We have constructed an interactive SBF model construction tool, called SBFAuthor, which will be used in several interactive environments. Here are a few examples.
7.1. ACT
SBF models are being used as the foundation for the Aquarium Construction Toolkit (ACT), an interactive learning environment for modeling aquaria as a complex system (Hmelo-Silver et al., Reference Hmelo-Silver, Jordan, Liu, Gray, Demeter, Rugaber, Vattam and Goel2008). The idea is that middle school students may be better able to understand a complex system such as an aquarium if they build a model of the system that includes not only its structural descriptions, but also its functions and behaviors. SBFAuthor is the interactive tool that will be used to construct these models. ACT also enables the students to simulate their models using NetLogo (Wilensky, Reference Wilensky1999). Hence, SBF models must be executable by NetLogo, and NetLogo provides an operational semantics for SBF. Thus far, we have been able to build useful interpretations for a subclass of SBF models, and we are actively working on others.
7.2. DANTE
SBF models are also the foundation for an interactive environment, called DANTE, for supporting biologically inspired design (Vattam et al., Reference Vattam, Helms, Goel, Gero and Goel2008). The idea is that representations of biological systems such as SBF models may facilitate analogical transfer of biological principles to engineering problems. DANTE provides another semantic interpretation of SBF models. It does this with a feature called a critic. Critics are reactive checkers of a user's models. Consequently, DANTE must treat SBF models as potentially being incorrect. The semantics of an incorrect model is the appropriate response (diagnosis and suggestion) from the relevant critic to the modeler.
8. SBFAuthor: AN INTERACTIVE SBF MODEL CONSTRUCTION TOOL
SBFAuthor is a computational tool for interactive construction of SBF models of complex systems. SBFAuthor adds a visual syntax for the SBF specification language described above. The utility of visual notation for modeling languages has been shown in practice through visual modeling paradigms such as the entity relationship (ER) model and the Unified Modeling Language (UML). Visual representations offer significant advantages over textual representations for model building and model comprehension. For example, Nosek and Roth (Reference Nosek and Roth1990) noted that semantic networks (graphs) are more understandable than their equivalent predicate logic (textual) representation. Particular knowledge representation frameworks such as concept maps (Novak & Gowin, Reference Novak and Gowin1984) are based on well-defined graphical notations.
SBFAuthor is an editor that facilitates building SBF models using visual notations. Figure 4 captures the correspondence between the elements of the abstract syntax of SBF specification language and their visual counterparts.
The visual syntax of the SBFAuthor. [A color version of this figure can be viewed online at journals.cambridge.org/aie]
SBFAuthor visually partitions an SBF model into three views: Structure view, Behavior view, and Function view, as shown in Figure 5. This figure depicts the SBF model of the Gyroscope follow-up shown in Figure 1.
A snapshot of SBFAuthor's main interface. [A color version of this figure can be viewed online at journals.cambridge.org/aie]
8.1. Structure view
The structure view enables users to create the
portion of the SBF model in terms of
,
and their associated
. The Structure model is presented as a graph. For each
or
, a corresponding node is created. The
are represented as labeled links between nodes in the graph. Figure 6a shows the structure view of the gyroscope follow-up presented in Figure 1. It consists of
nodes like “
,” “
,” “
,” and so forth. It also contains a
node “
.” Links between these nodes indicate specific kinds of
like “
,” “
,” and so forth.
The structure view: (a) a structure model of a gyroscope follow-up and (b) a substance dialog box. [A color version of this figure can be viewed online at journals.cambridge.org/aie]
and
can be described using dialog boxes (see Fig. 6b) that can be invoked to enter their feature values (e.g., “
,” “
”) and to include their
(e.g., “
” and “
” in the case of “
”). According to the SBF specification, a
can itself comprise a subsystem with its own SBF model. In such situations users can create a separate SBF model for that
and include a reference to the
of that model in the parent model.
8.2. Behavior view
The behavior view allows users to create the
portion of the SBF model by allowing them to create one or more
which appear as different tabs in the behavior view. For each
, users can create
and
. Each
is represented as a state-transition graph as shown in Figure 7a. Every
and
is associated with a dialog box. Recall from the SBF specification that
can constrain the values of
The
dialog box allows the user to model
variables and their values by choosing them from a list of
derived from the
For example, Figure 7b represents “
” of the behavior model constructed in Figure 3. The variables “
” and “
” of “
” are assigned values “
” and “
” respectively. These variables are derived from the
.
The behavior view: (a) a specific behavior and (b) state and (c) transition dialog boxes. [A color version of this figure can be viewed online at journals.cambridge.org/aie]
Recall that
capture the
in the form of references to various model elements (like
, etc.). The
dialog box enables a user to express this information. For instance, in Figure 7c the
named “
” contains a reference to the
.” This captures one of the causes for the
between “
” and “
,” reflecting the
of a particular linkage to allow angular momentum to move from the gyroscope to the pivot.
8.3. Function view
The function view allows users to create the
portion of the SBF model as one or more
that appear as different tabs in the function view as shown in Figure 8. For each
users can state its type (
or
). If the function being modeled is a
, the user can choose from an existing set of
that are present in the teleology. If it is a
, the user has to define the new
and include a reference to a
that accomplishes it. In Figure 8, for example, the
“
” is accomplished by the
“
.” In addition to the reference to a
, a user has to specify a
labeled “
” (e.g., “
” in Fig. 8) and a
called “
” (e.g., “
” in Fig. 8) associated with that
, which the user can specify by either choosing
existing in the
or by creating new ones. In accordance with the SBF specification, users can also include a reference in the function view to an external
that initiates that
.
The function view. [A color version of this figure can be viewed online at journals.cambridge.org/aie]
9. CONCLUSIONS
Research on engineering design and problem solving has developed several ontologies for expressing teleology. The literature typically describes these ontologies only at a high level, often using teleological models of specific systems as illustrations. However, the development of interactive tools for constructing teleological models of complex systems requires a more precise specification of the ontology. Giving a formal definition to SBF leads to a variety of benefits including precision, consistent usage, and tool building. Each application of the SBF language requires not only the abstract syntax and static semantics but also a concrete syntax and a dynamic semantics. The precise specification potentially enables a range of additional automated capabilities such as model checking, model simulation, and interactive guides and critics for model construction. In this paper, we viewed SBF as a programming language. We specified the abstract syntax and the static semantics of the SBF language. The next step in our work is to develop the precise dynamic semantics of the language; in this paper, we merely pointed to earlier work that illustrates the dynamic semantics. The SBF language captures the expressive power of the earlier programs and provides a basis for interactive construction of SBF models. We also described an interactive model construction tool called SBFAuthor that is based on the abstract syntax and static semantics of the SBF language.
ACKNOWLEDGMENTS
Over the years several people have contributed to the development of the SBF language, especially Sambasiva Bhatta, Sattiraju Prabhakar, and Patrick Yaner. This paper has benefited from discussions with Michael Helms and Patrick Yaner. The domain of aquaria was suggested by Cindy Hmelo-Silver and Rebecca Jordan, and the ACT project is joint work with them. The DANTE project is in collaboration with Georgia Tech's Center for Biologically Inspired Design. This research is supported by NFS (IIS) Grant 0534622, NSF (ALT) Grant 0632519, and NSF (CreativeIT) Grant 0733363.
Ashok K. Goel is an Associate Professor of Computer and Cognitive Science and Director of the Design Intelligence Laboratory in the School of Interactive Computing at Georgia Institute of Technology. He received his PhD in computer and information science from Ohio State University in 1989. Dr. Goel's research interests are in using cognitive models and artificial intelligence techniques to address problems in design, including creativity in design.
Spencer Rugaber is a Senior Research Scientist in the College of Computing at the Georgia Institute of Technology. He received his PhD in computer science from Yale University in 1978. His research interests are in the area of software engineering, specifically reverse engineering and program comprehension, software evolution and maintenance, and software design. Dr. Rugaber has served as Program Director for the Software Engineering and Languages Program in the Division of Computer–Communications Research at the US National Science Foundation and as Vice-Chairman of the IEEE Technical Committee on Reverse Engineering.
Swaroop Vattam is a graduate student in the College of Computing at the Georgia Institute of Technology. He is a Research Assistant in the Design Intelligence Laboratory, where his main interests are design cognition, knowledge capture and sharing, human–computer interaction, and the use of artificial intelligence (AI) technology to enable communicative interactions between humans and computers. He is currently exploring the domain of biologically inspired design and investigating the use of AI technology to aid engineers in seeking and utilizing knowledge of biological systems to develop innovative design solutions.
