Supporting Event-Driven Activities in a Distributed Design Environment

1 Introduction

Design is an inherently collaborative and, hence, social process between individuals who often come from disparate professional backgrounds, requiring the negotiation and reconciliation of different views, perspectives, vocabularies, and knowledge bases associated with a design artifact¹ [n-dim95]. The bulk of a designer's² time is spent negotiating various aspects of a design and organizing and structuring design information in ways understandable to them [Levy93]. In fact, design studies have shown that designers spend as little as 15% of their time doing standard analytical tasks [Engl90]. The balance of their time is spent in collaboration with co-workers and making sense of these collaborations.

The very nature of collaboration is changing with the evolution of information dissemination and retrieval technology. With such technological advances as the World Wide Web and the Internet, and fast and cheap personal computers and workstations, collaboration with co-workers via the corporate memo and face-to-face meetings is being replaced by e-mail, `information pull' on the Web, and corporate intranets. Where once there was personal contact, whether in formal design meetings or informally at the water cooler or in the hallway, there are now telecommuting workers in virtual offices and distributed design teams. The collaborative nature of engineering design is becoming more impersonal as the actors become more distributed, both geographically and temporally, and as they come to rely more and more on the computer in the workplace.

What consequences does this have for the designer? Design activities are often event-driven; that is, certain activities should be initiated upon the occurrence of certain events or the detection of certain states in the design. These activities are initiated and carried out by designers when notified of an appropriate triggering event or design state. We see designers playing the roles of event detector, activity initiator, and activity executor. Increasingly in the future, the designer, in the role of activity initiator, will be forced to respond to electronic events to which he is ill-suited to detect and respond in a timely manner, e.g., an e-mail containing important design changes languishes in an inbox, or new information appears on the corporate intranet that renders unnecessary, wasteful, and/or redundant the designer's present work task. New electronic technology will increasingly supplant the social interaction that the designer presently relys upon for notification. The present situation is far from perfect; it is not clear that the future will be better.

The notification problem as described above is but one of a host of interrelated problems that plague designers. The focus of design research is changing to address the problems common to designers of all disciplines, by focusing on supporting common, generic, non-discipline related tasks. The product of Bañares-Alcántara's research, ÉGIDE [Baña95] focuses on helping designers manage design alternatives, using a IBIS-like [Kunz70] tool for assisting designers in their collaborative effort. Jacome and Director [Jaco95] have created Minerva, a framework that supports design planning and management. Thomas [Thom96] extols the benefits of integration of discipline-specific analytical tools into an information management environment.

The focus of this research is to support designers of all disciplines in both their common and discipline-related tasks. The utility of the result of this work, in a chemical engineering context, will be shown. The hypothesis is that as designers become more distributed, breakdowns in communication will negatively affect the design process. A design support system should support designers in their roles as event detector and initiator and executor of activities by allowing rules to be written about design data. The two major rule paradigms in active databases, to which this work relates closely, are condition-action rules, a superclass of event-condition-action rules. Qualitatively, the operation of {E}-C-A rules can be stated as {On event then} if condition then do action.

Writing rules about design data would allow automatization of many of the processes which designers now manually carry out, such as checking design constraints, bringing derived data into consistency, model legality enforcement, and change notification. The following is a proposal to allow designers to specify events and/or conditions in a design support environment which, when met, automatically allow corresponding actions to be taken.

The rest of this document is organized as follows: Section 2 describes general requirements of a design support system. Section 3 summarizes some current implementations of design support systems. Section 4 gives a detailed description of the selected design support system, n-dim. Section 5 summarizes work completed to date, including an application of rules. Section 6 discusses events in detail, and Section 7 summarizes the proposed work and its evaluation.

2 Requirements of a Design Support System

The requirements of a design support system derive necessarily from the activities of the designers that are supported by them. Thus, any manifesto of requirements must be drawn from observations of engineers engaged in engineering design. The following list, though admittedly incomplete, has been constructed from several observations and studies.

Collaboration and sharing of information. Collaboration is at the very heart of team-based design. Negotiations continually take place among participants in the design process to resolve ambiguities about the artifact [Subr89]. Even in the trivial case of a designer designing an artifact to be produced by himself for himself, design involves collaboration with himself in the roles of designer, producer, and consumer [n-dim95]. In order to properly support designers, information dissemination and exchange should be allowed and encouraged in a design support environment. Currently, most electronic information sharing is accomplished via `pull' technology (e.g. search engines on the Web), but there is growing research on `push' technology, where information of interest is delivered to the interested party in a timely fashion [Kenl97].

Design knowledge capture and reuse. Organizations make a substantial investment in developing design knowledge; maintaining this knowledge for subsequent reuse by other designers allows organizations to design more cost-effectively [n-dim95]. The problem of designers retiring and taking their knowledge with them out of the organization is well known [Wear93]. Archiving corporate knowledge is not enough; designers need to be able to search over the knowledge repository to find information relevant to the current problem. A design support environment should allow design knowledge to be captured, stored, searched over, and reused by designers endeavoring on future projects.

Design decision rationale capture. Oftentimes the rationale behind design decisions is not recorded, leaving those who would reuse portions of a previous design wondering why certain decisions were made in the first place. Post-hoc documentation of rationale may not be sufficient, as rationale for certain decisions may have changed over time as requirements changed or as designer memory faded. To prevent costly mistakes from being repeated, the rationale behind design decisions should be captured with the highest possible fidelity, with the aim that in the future the rationale behind design decisions is clear.

Tool integration. Manipulation of data from one format to another (e.g. simulation output serves as input data to a spreadsheet) is a common task among designers. Data manipulation can become involved as the tools employed become more and more sophisticated. Integration of the tools used by designers into a support environment allows automation of these processes, as well as reducing errors of transcription. Levy, et. al., warn, however, that a partial integration of tools is insufficient to achieve design efficiency [Levy93]. A design support environment should allow the full integration of all tools used by designers.

Evolutionary System. The work practices of designers are in a state of continual change. Personnel changes, new versions of support tools, technological advances, and changing market conditions all can prompt or force a designer to modify his work habits and practices. Cunningham [Cunn96] advocates giving the end-user the ability to modify the support environment directly; he claims that in this fashion the requirements of the users are more quickly met. At the very least, a design support system should be able to change with the designer to provide continuous support, whether or not the end-user does the modification.

Scalable. As designers become distributed, all of design's requirements will be imposed over increasingly large networks. Geographically distributed post-relational databases suffer from scaleup problems as the number of nodes³ in the network increases [Gray96]. Next-generation databases under development [Ston96] potentially do not suffer from scale-up problems, and can better support a work anytime, anywhere criterion. A design support environment should both distribute well and scale well to a large number of nodes.

3 Current Design Support Systems

With these features in mind, a design support system in which to accomplish the proposed work must be chosen. Since the aim of this work is to support designers of all disciplines, including chemical engineers, the following abbreviated survey of related work is not necessarily drawn from research specific to supporting chemical engineers engaged in design, but from disciplines where the requirements listed above are applicable as well.

IBIS/gIBIS. Early work on capturing the structure of negotiations in a design environment was done by Kunz in the late 1960's [Kunz70]. Kunz and Rittle developed IBIS, the Issue-Based Information System, as a means to model the conversations that occur between participants in a shared task, namely design. IBIS uses a stringent classification scheme to organize the conversation data in a graph structure. There are three node types (issues, positions, arguments) and eight link types (responds-to, questions, is-suggested-by, supports, objects-to, specializes, generalizes, replaces). Conklin and Begeman later developed gIBIS, a graphical version and modest extension of IBIS [Conk88]. gIBIS is a sophisticated environment which includes context-sensitive menus, multiple indexes (subject, author, keyword, title), user configurations, link filtering, simple queries, multi-user access, and pointers to external objects.

The authors have noted some difficulties with this system, most notably the problem of cognitive overhead⁴ produced by the high degree of structure. While providing a way for participants to model discussion and implicitly capture decision rationale, gIBIS does not provide support for the other aspects of design: use of analytical tools, reconciliation of design alternatives, etc. It is not clear that features, needed now or otherwise, are easily added.

ÉGIDE. ÉGIDE (ÉCOSSE Graphic Integrated Design Environment) is a prototype design support system for conceptual design of chemical processes [Baña95]. ÉGIDE is based on KDBS (Knowledge-Based Design System), a prototype design support system for chemical process engineering. KBDS was created to test and develop ideas about the representation of the design process, and to demonstrate how such a representation can be used to support design activities [Baña94]. ÉGIDE is an extension of KBDS, enabled with an IBIS-like tool for design rationale expression. ÉGIDE represents the design process by maintaining information about the artifact in three spaces: the design objective space, the design alternative space, and the design models space. Design alternatives are linked to other design alternatives; ÉGIDE maintains a representation of an alternative's constituent sub-alternatives, their relation to each other, and to sub-alternatives in other design alternatives, allowing refinement of alternatives as the design progresses. The entire history of the design of a chemical process is captured by maintaining the relationships between antecedent and successor designs. In addition, ÉGIDE monitors consistency among coupled sub-designs, allows navigation of the design spaces via a graphical user interface, and interfaces transparently to external applications for evaluation of design alternatives (with respect to the objectives for which they were created). ÉGIDE augments this by allowing IBIS networks to be attached to the design history, storing every decision along with its competing alternative decisions and arguments used in the selection. An IBIS network may also be interrelated with other networks; a network is maintained for every problem and issue discussed.

ÉGIDE's major drawback is that it is strictly a chemical engineering design support system; it is not designed to support anyone other than chemical engineers. Consequently, the non-chemical engineering members of a multi-disciplinary design team may be under-supported, possibly degrading the efficiency of the entire team's design process. In addition, ÉGIDE is not suitable for supporting the design of anything other than a chemical process. A team whose design purview extends beyond this domain may also be under-supported, again possibly resulting in design inefficiency.

Minerva. Jacome and Director have proposed a formalism for representing design processes [Jaco95]. An implementation of a design process planning and management tool that uses this formalism is called Minerva. In this formalism, design objects are characterized by property definitions and behavioral specifications, each of which may be partitioned into requirements, restrictions, and descriptions. Classes of design objects which share properties can be defined and organized by discipline in a discipline hierarchy, according to levels of abstraction and specialization. Design objects can also be organized into a design process hierarchy, where objects are classified according to their level of abstraction and level of functional and structural decomposition.

The design process in Minerva is modeled as an arbitrarily complex, partially ordered sequence of generation design steps and test design steps taken to meet design objectives. Minerva allows designers to generate and execute design process plans, automatically reformulates design plans in the case of impasse during plan generation or execution, and provides support of backtracking for redesign and for problem redefinition. Jacome and Director claim that Minerva is discipline independent and can be customized to any design discipline.

VSSCD. Santoyridis, et. al., are implementing VSSCD, an Object Versioning Support System for Collaborative Design, for use in a concurrent engineering context [Sant97]. VSSCD is an application being built directly on top of an OODBMS (Object-Oriented DataBase Management System). Like ÉGIDE and Minerva, the premise for VSSCD is that designers generate a progression of alternatives and refinements of the artifacts they design. Santoyridis, et. al., tested their initial conceptual model of VSSCD by conducting an experiment with a group of designers asked to prepare the conceptual design of an artifact; the designers were divided into three groups assigned to different components of the artifact in order to simulate concurrent design. The results of this experiment prompted Santoyridis, et. al., to modify their original concept somewhat, finally settling on a versioning scheme in which versions may be in one of three states: transient (i.e., viewable and modifiable by a single designer), working (viewable and modifiable by a group of designers), or released (viewable to all but immutable). Design artifacts may be composites of other artifacts, all of which may be in one of the three states listed above. VSSCD is generic, and can potentially support designers in any discipline, although the authors make no mention of the integration of external tools to support specific disciplines. A prototype of VSSCD has been implemented; the authors are focusing on testing this prototype.

n-dim. n-dim (n-dimensional information modeling) is a design support environment under development at the Institute for Complex Engineered Systems⁵ at Carnegie Mellon University. n-dim is a general modeling environment that allows users to share information, to interrelate diverse types of information using nodes-and-links graphs in a context that is meaningful to them, and to capture the evolution of the information. By maintaining this evolution, the information is made persistent for recall and reuse by future users. In addition, other design support tools can be easily integrated into n-dim, allowing designers to perform, in one environment, activities that previously would have been done separately. n-dim is a generic environment, permitting users to tailor the environment to suit their specific needs, and can thus support a cross-disciplinary design team more effectively.

While there are pros and cons to each of the systems detailed above, and to others which I have studied, there is one drawback apparent in all: the lack of electronic support for the generation of, and response to, events that occur among the members of a distributed design team. The work proposed in this document aims at addressing this deficiency. Based on the work completed thus far, my familiarity with the n-dim system and the philosophy behind it, and the ready availability of the environment, I have decided to propose work that involves extending n-dim by allowing users to write rules about design data stored in it. The following section goes into further detail about how n-dim's features support designers through the use of a small chemical engineering example.

4 Selected Design Support Environment

n-dim was created as a tool to gather empirical data about design and the way designers work; like KBDS, it also serves as a test bed for implementing solutions to some of the problems already well established in this domain [Levy93]. n-dim has undergone three generations of development, from a Macintosh hypertext version to a multi-machine, multi-user system today. n-dim is built using objects in a programming environment called BOS (Basic Object System), which itself is implemented in C. BOS is an experimental, prototype-based, object-oriented toolkit aimed at better supporting evolutionary software development [Duto96]. BOS objects are accessible via an interpreted language, called stitch, or C. n-dim is written in stitch, with some critical methods moved to C for performance benefit. n-dim objects are made persistent by storing them in a post-relational database. The DBMS in use currently is an object-relational DBMS called Illustra. It is not a distributed DBMS; n-dim developers and users need storage capability while developing the environment, so Illustra (or some other centralized DBMS) will continue to be used until a suitable distributed DBMS is developed that does not suffer from scaleup problems. In this work we assume that issues related to distribution of data and rules to sites in a distributed network will be addressed by others; we will endeavor, however, to make all work implemented here be easily extended to a distributed environment.

n-dim itself consists of three modules, named Modeling, UI, and Storage, all of which communicate internally. In addition, the UI module communicates with the graphical widget toolkit to generate user interfaces and respond to user events (e.g., mouse clicks, etc.). The Storage module interfaces with an Illustra module, which in turn communicates with the Illustra DBMS via a C API⁶. Codebase statistics for these and the BOS module can be seen in Table 1. Currently, n-dim and BOS comprise 1,483 files occupying 8.68 megabytes of memory⁷.

Table 1. n-dim/BOS Codebase Statistics.
	Modeling	Storage	UI	Illustra	BOS	Total
C files/lines	26 / 5,869	0 / 0	0 / 0	11 / 3,906	228 / 179,720	265 / 189,495
stitch files/lines	58 / 13,865	7 / 6,035	32 / 15,275	7 / 3,930	81 / 10,427	185 / 49,532
Bytes	583,949	158,145	411,213	233,812	5,601,133	6,988,252

Since n-dim is a generic modeling environment, its salient features are best illustrated by example.

Generalized Modeling. Suppose an engineer wants to compute the total capital cost of all equipment shown on a proposed process flowsheet. Using n-dim, he may create an information model, say Capital Cost, to aid him in this task. First, the engineer picks the information that he wants to appear in the model, e.g. Process Flowsheet, Equipment Cost Reference, etc. Next, he describes the relationships between objects participating in Capital Cost by creating links between some or all of the objects. Examples of such models appear in Figure 1.

The object space in n-dim is flat; that is, there is no hierarchical structure imposed on information, save the structure the user wishes to impose; in this manner `cognitive overhead' is minimized. The models that appear in Capital Cost above (Process Flowsheet, Equipment Cost Reference, etc.) are not actually contained in Capital Cost; a model in n-dim is only a list of relationships, or links. The icons symbolize links that declare Process Flowsheet, Equipment Cost Reference, etc. are taking part in Capital Cost. Information models may take part in an arbitrary number of models. The directed arrows in the models above are links created by the user to show relationships between various "parts" of Capital Cost and Process Flowsheet.

Figure 1. The n-dim models Capital Cost and Process Flowsheet

Tool Integration. Users may attach operations to models. An operation is a piece of stitch code that provides a desired functionality. This functionality may involve the invocation of standard analytical tools, like ASCEND, as seen in Process Flowsheet. In Capital Cost the engineer creates two operations to do the desired task: Generate Equipment List and Calculate Plant Cost. Generate Equipment List descends into Process Flowsheet and generates a comprehensive equipment list, placing the result in Total Plant Equipment List. Calculate Plant Cost computes the extended cost of each item by referring to Equipment Cost Reference and Total Plant Equipment List, takes the summation over all the items, and places the result in Total Plant Capital Cost. These operations may be set up to do these tasks recursively so that all parts of Process Flowsheet and Total Plant Equipment List are iterated over, no matter how "deep" these models are.

Collaboration. As designers become experienced and learn more about the design of an artifact, the design and design process may become refined to the point where a group may want to formalize the structure of certain models. This is done via modeling languages. A modeling language defines the set of links that are legal in the model under construction. The model under construction will also inherit any operations defined on its modeling language. It can be thought of as a template for construction of a new model. Every model in n-dim has an associated modeling language. The modeling language of Capital Cost is a built-in system language called Universal, which places no restrictions on the type of links in the model and has no operations attached. Engineers who do repeated capital cost estimation may wish to construct their cost estimation models in the Capital Cost language, thus assuring that no illegal parts can be added to their models and that the operations defined on Capital Cost are automatically available in their models.

Persistence. By default, a model is private upon creation and cannot be seen by any other n-dim user⁸. In this manner users may create models of information and not share them with any other user. A user is free to modify a private model in any way he chooses; however, the history of these changes is not captured. At some point in model development, a user may wish to collaborate and share a private model with other users by making it public. Public models may be viewed and modified by any n-dim user; a revision history is maintained by n-dim such that any public model can be returned to the state it was in at any previous point in time. Since public models can be perfectly reconstructed, changes are never really lost; public models are said to be incrementally mutable [Nest87]. Both private and public models may be published. Published models may be viewed by all n-dim users as well; however, edits to published models are disallowed, making them immutable. Revising a published model, like revising a book, involves publishing a revision of the original model.

Evolution. An engineer may use the publishing mechanism in the following manner: When Capital Cost is refined to a point where it is usable, it is published, making it immutable. A copy is made (which is private) and then immediately made public. Further refinement of this copy, say Capital Cost 2, is now possible by the group while preserving features of the language that cost estimation models are built in, namely Capital Cost. Whenever desired, Capital Cost 2 may be published and used as a language (but not necessarily in that order.) The cycle of continuous refinement, using the public model as a common field of work, supports both collaboration and evolution.

Methodology. The n-dim group has, over time, developed methodologies for developing design support systems for industrial clients. The process is an iterative one, involving study of the design work, creation of a tool or system to support the work, and evaluation of the system by studying the new work environment after system deployment. The group starts small and iteratively builds up to an integrated system, assuming all the while that the tool under development will fail to adequately support designers in the first few rounds of development. In this way, the group hopes to rapidly converge to a larger, more reliable, and useful system [Subr97].

5 Completed Work

In the 21 months since joining the n-dim group, I have been working on multiple fronts in preparing to perform the work proposed herein. C is generally the language by which software tools talk to each other; n-dim, BOS, and expert system shells are no exception. A rudimentary proficiency in C is necessary to carry out the proposed work. Basic knowledge of databases and expert systems is also required. Towards these ends, I have taken courses in C, engineering databases, and expert systems.

I have been involved with the maintenance and development of n-dim, BOS, and applications written in them. I have fixed numerous bugs in n-dim, and have been involved with the development of RIFE, a document management application for an industrial sponsor that uses n-dim with a custom web-browser user interface. Both of these tasks have allowed me to become proficient in stitch, as well as gain a preliminary understanding of the n-dim implementation in BOS.

In order to learn the `under-the-hood' details of n-dim and BOS, I have implemented the functionality of cardinality checking with respect to model legality in n-dim. Currently in n-dim, a model is legal if all the links that appear in the model also appear in the model's language, and are interconnected in the same fashion; there are no restrictions on the number of links that may be present in an instance of a language. The cardinality checking feature allows n-dim users to specify how many of certain types of links may be present in instances of languages. Implementing this feature required making pervasive changes in all modules⁹ of n-dim, including the Illustra module and the underlying database schema. To show the utility of cardinality checking, a small example is in order.

Consider the example of Flowsheet modeling; what should be the cardinalities of links between hypothetical Stream and Flash Unit models? The specifications that the user is allowed to make in n-dim concerning these link cardinalities are best shown graphically; consider the partial Flowsheet language specification shown in Figure 2. This specification may be interpreted as follows: In the Flowsheet language, there must be 1 or more Stream models, and 0 or more Flash Unit models. Each Stream model must be the source of 0 or 1 feeds links whose target is in Flash Unit language, and the target of 0 or 1 produces links whose source is in Flash Unit language. Each Flash Unit model must be the source of 2 or 3 produces links whose target is in Stream language, and the target of 1 feeds link whose source is in Stream language. Any model in Flowsheet language whose link cardinalities violate the specification is judged to be illegal.

Figure 2. Partial cardinality specification for the Flowsheet modeling language.

The algorithm for checking cardinality involves two iterations: one over the language model to build up the acceptable cardinality list, and another to count the links in the instance of the language. The same functionality can be provided with rules. I have authored a small rule system in an expert system shell called CLIPS (C Language Integrated Production System) that implements this functionality. A model and its language can be output to a text file, via a stitch operation, as a series of facts to be read into CLIPS's working memory. The model legality rules are then loaded and run, and CLIPS returns a `legal' or `illegal' judgement. Currently, this process is totally manual; part of the proposed work is to automate this process by allowing an expert system shell to be invoked from within n-dim.

In performing this task and the ones listed above, I have accumulated significant knowledge of how the various modules of n-dim interact. I am confident that I possess the ability to implement (or at least quickly learn how to implement) features much more considerable in scope and utility.

6 Events in a Distributed Design Environment

The overall goal of this work is to better support designers of all disciplines, both in their common and discipline-related tasks by allowing rules to be written about design data; this will allow automatic initiation of activities that designers currently initiate manually. In order to allow designers to write rules about design data, designers need to be able to express the concepts of event, condition, and action. The latter two concepts translate nicely into the if/then paradigm familiar to programmers; what of the former? What are the electronic equivalents of events in a distributed design support system? How does one express an event in a rule in a distributed design support system? In order to answer these questions, it is useful to examine current means by which designers initiate activities.

6.1 What is an Event?

In the context of engineering design, an event can be defined as the design artifact's attainment of a certain state. Events, then, are produced during the execution of a task¹⁰. Associated with any arbitrary event are various actors:

• Interested Party: A designer who wishes some action(s) to be initiated upon the occurrence of an event.
• Event Generator: A designer whose action(s) causes events.
• Event Sensor: An entity who watches for the occurrence of interesting events and passes this information to an Event Transmitter.
• Event Transmitter: An entity who relays information about an interesting event to Interested Party(ies).
• Action Agent: An entity who performs action(s) at the behest of an Interested Party.

Due to the growing distributed nature of design, designers, in their roles as interested parties, are becoming more dispersed with respect to designers as event generators. Hence, the generation of an event does not necessarily guarantee notification of interested parties of their occurrence. This may lead to (from the event generator's perspective) delays or failure to initiate an activity.

How, then, are interested parties notified of the occurrence of events of relevance to them? What are the electronic equivalents in a distributed design environment? The following discussion attempts to delineate the various ways in which the agents listed above cooperate to initiate actions based on attained states in a design, and possible electronic equivalents. The methods employed by these agents vary with the amount of information possessed by the event generator and interested party about the event in question.

Interest Awareness. Since design tasks may be distributed among members of a design team, there often are dependencies in scheduling tasks assigned to various members of the team. A designer, as an event generator, may be aware that events he generates are of interest to an interested party (e.g. due to the nature of the task). In this case, the event generator directly notifies the interested party of occurrence of the event, which in turn initiates the appropriate activity. If the event generator is not aware of some other actor's interest, how does it become aware of this interest?

Oftentimes the generator of interesting events is known to a designer responsible for a task dependent on the generator's. An interest in the status of the generator's task can be registered with the generator, requesting notice be sent to the interested party when that task reaches a certain state. The onus of event detection and notification of event occurrence then falls to the event generator. Due to human fallibility, relying solely on interest registration for notification of occurrence of relevant events can be catastrophic: There may not be a backup policy to initiate a dependent task.

In a distributed design environment, nodes in a network that hold interesting data or are expected to generate interesting events could keep a list of entities to notify when something of interest to them occurs; optionally, an action to take upon detection of an interesting event could also be included on the registration of interest. Even if it is not known who will be generating events of interest, all nodes in the network could be made aware of interesting events and the corresponding interested party; periodically, or for every event that gets generated, the node performs a lookup to see if any other entity need be notified¹¹. Alternatively, a query or search functionality to find nodes which generate interesting events could be provided.

Status Checking. Status checking may be employed as a notification policy in its own right, or simply to augment interest registration. It involves interrogating an event generator responsible for a task as to the state of that task. This interrogation can be performed in a haphazard manner (e.g., in an occasional phone call) or periodically (e.g., in a weekly design meeting). The detection of the occurrence of an event is inferred from differencing the results of the previous query with the present one. Here, the onus of detection of occurrence (and therefore notification) shifts back to the interested party.

This could be modeled as a haphazard or periodic query to a distributed database; the query would either look in an event table of some sort, or directly look for conditions in the database to match the interesting criteria¹². Most of the time, however, the event and/or the condition of interest has not occurred or arisen; system resources would have been expended executing the query with a negative result. Also, notification of interesting events might not transpire quickly enough; if the Dt between successive queries is 1/2 hour, and an important interesting event/condition of interest occurs/arises 5 minutes after the last query; notification doesn't occur for another 25 minutes!

Event Broadcast. The above methods assume that an interested party knows whom to ask about interesting events. Furthermore they assume that an interested party knows that there are events of interest occurring! Clearly, status checking is inapplicable when the interested party doesn't know whom to ask about interesting events; interest registration is useless if the interested party doesn't know that there are interesting events occurring at all. However, by general agreement, a design team may decide on a set of events to notify other members of the design team as they occur. In this fashion, members can become aware of events generated by the team, and respond to events of interest. Each designer, as event generator, also performs the combined tasks of an event sensor and event transmitter, transmitting the occurrence of agreed-upon interesting events to the design team. The onus of detection and notification, then, is on each member of the design team, in their roles as event generators.

In a distributed system, event broadcast could be modeled as a message send to every other node in the network, for every activity attempted or completed, for every node in the network. Nodes then filter through this stream of event notices, and act on events of interest. This has the potential for greatly increasing network traffic and node resources, depending on the granularity of the events broadcast (e.g., do mouse clicks in a user interface count as events worthy of being broadcast over the network?). Even this model, however, has the potential of not alerting every entity on the network, as nodes could be added to the network (e.g., new members are added to a design team) without global knowledge.

6.2 Expression of Events

It is unlikely that simple events like the ones defined above will be adequate to meet designers' needs. It is easy to imagine the initiation of a designer's work activities depending on the status of not one but several co-workers. Thus, the combination of an arbitrary number of events is desirable to be expressed by a designer in a rule, including negation of events (e.g., if an event did not occur, then perform some action). In addition, the initiation of a designer's work activities will probably also depend on time as well. One can imagine the scenario of delaying the initiation of a work activity `until the last minute'; presumably, the time that the task is initiated is calculated from the due date/time of the task and the task's expected duration. Accordingly, designers should be able to express the requirement for sequences of events, simultaneous events, and explicit time events, including negation, conjunction, and disjunction of these events. Motakis and Zaniolo [Mota95], among others, propose a formal semantics for composite temporal events in active database rules.

All networks are subject to outages, i.e., periods when there is little or no connectivity between nodes. An outage can be as small as a single node disconnected from the rest of the network for a few milliseconds, or as large as all nodes disconnected from all other nodes in the network for extended periods of time. In either case, data transmission (and hence notification of events) may be delayed. Increases in network traffic can result in network slowdowns, also delaying transmission of data. These delays in notification may have unpredictable effects on the firing of rules which deal with events whose notification is delayed. For example, a user might author a rule that depends on a sequence of events occurring. If the events occur in the prescribed order, but are reported to the rule in the incorrect order because of network difficulties, should the rule fire or not? In addition, the lack of a global clock¹³ among nodes in large distributed networks makes specification of the temporal aspect of an event undependable. Current rule languages are insufficiently rich to deal with complexities of this sort; a user should be able to specify (for at least a few common cases) what to do in the case of network disconnectivity or obvious asynchronicity.

7 Proposed Work

7.1 Implementation of Rules

There are several ways to implement an event monitoring/detecting and action initiation functionality in n-dim. The three ways that I propose to make use of are event brokers, expert system shells, and/or rules in the underlying database.

Event Broker. An event broker is an entity that allows one to register event types (specifying an event generator object and legal event names that the object can generate), and register event handlers (specifying, for an event generator object/event name pair, a message to send to a specified object). The event generating object simply then tells the event broker which event has happened and who generated it. The event broker responds by sending the appropriate message to the specified object. There are event broker objects defined and ready to use in stitch¹⁴. In Java (and other object-oriented languages), there are similar classes of objects called Observers which function in much the same way.

An event broker is useful when there is a list of known events types and entities that can generate these events, and when the objects generating events know that they should be notifying the event broker of the occurrence. Given these constraints, event brokers are suitable for use in building applications, where the list of entities generating events and the number of event types is known a priori and is relatively small.

Expert System Shells. An expert system is a program which is specifically intended to model human expertise or knowledge. The word `shell' is reserved for the portion of the software that performs inferences, or reasoning. There are three basic elements of an expert system shell: a fact-list (also called `working memory'), a knowledge base (i.e., rules), and an inference engine, which controls overall execution of rules [Giar93]. The shell functions by matching patterns in rules against data in working memory; when a rule's pattern is fully matched, the corresponding action is taken¹⁵.

CLIPS and JESS (Java Expert System Shell) are two of a myriad of expert system shells that are callable from other programs; I propose to make use of one or both of these shells to accomplish this work. There are at least two modes of operation of an expert system shell with an environment like n-dim. One mode of operation is analogous to calling a subroutine from a main program: one passes data and a set of rules to the shell, and the shell iterates on the data until no more rules can fire. The result is then returned to n-dim. This has the effect of limiting in scope the effect of the rule system, as the rules can only act on the data passed to it.

A second mode of operation involves a continuously running expert system shell attached to a user's n-dim process, with all data that is held in n-dim's core memory also passed to the shell and vice-versa. As new facts are asserted or retracted, in either n-dim or the shell, a corresponding change is made in the other environment. As new rules are authored, a search facility would find relevant data and bring it into working memory as well. In this mode, expert system shells are able to handle situations in which event brokers fail to provide notification of occurrence, since they are capable of matching patterns specified by the user over the user's entire information space.

Both expert system shells and event brokers are restricted to the user's purview of the data and events associated with it. Each n-dim user's process `talks' with the database, but there is no inter-process communication. Therefore, each user's expert system shell would not be able to detect events generated by another user, even if events are generated while using n-dim at the same time. A database server, between the Illustra (or the current DBMS in use) module and the n-dim Storage module could provide the necessary inter-process communication capability, thereby allowing the shell to react to events generated by other users.

Database Rules. Most post-relational database management systems implement rules themselves. In this case, the DBMS rule manager itself intercepts transactions on the database and tries to match patterns on its list of rules. If a pattern is matched, the corresponding action is appended to the current transaction, and the rule base is checked again, possibly firing more rules. This process repeats until no more rules are fired; the transaction is then committed with the usual DBMS transaction atomicity guarantees¹⁶.

n-dim's underlying DBMS, Illustra, allows one to write rules about data stored in the database. Augmentation of the Illustra module to allow manipulation of database rules, and construction of a rule manager in n-dim Storage module, would need to be done. Use of database rules poses concurrency issues, as there might be direct manipulations to data in the database while there are copies of the same data in n-dim core memory. Also, rules might perform actions that would otherwise be invalid in n-dim (e.g., switching a model's status from public to private).

There is additional work common to all three cases listed above to make rules more useful to designers. There must be a graphical user interface to allow users to create, view, edit, suspend, and delete rules. A method of debugging large rule systems, whose behavior is non-deterministic (especially in light of the disconnection issues mentioned above) is desirable. Chakravarthy, et. al., are developing a visualization and explanation tool to aid rule authors and maintainers to better understand the behavior of large sets of rules [Chak95]. Their application provides a post-execution trace of a rule system's actions, showing the state of the database and rule base at any instant in time, thereby providing a context for the firing of each rule. Future work includes an interactive, real-time debugger for observing the dynamic behavior of a rule system [Chak95]. Static, pre-execution analysis methods [Bara95] are available for the identification of rule systems which, when executed, may lead to infinite cycling (i.e., the action of a rule fires another rule, which leads to the firing of the first rule, ad nauseum). Inclusion of tools of these sorts as they mature will help designers author and maintain rule systems.

7.2 The Proposed Work

The selected design support environment, n-dim, is in the midst of a reimplementation. The BOS programming environment, while allowing developers to more easily prototype features in n-dim, is slow. Critical parts of the n-dim code have been moved from stitch to C for performance benefit; to gain further performance benefit, more sections must be moved to C. However, moving more and more code to C destroys the rapid prototyping features of the environment. Therefore, it has been decided by the n-dim group that the n-dim code base will be moved to C++, an object-oriented variant of C. C++ supplies an object-oriented environment for development, similar to BOS, as well as a fast run-time system. Certain new features, like revision management and cardinality checking, will be added during the reimplementation effort. In order to more fully understand the inner details of the n-dim architecture, I will participate in this reimplementation effort. The knowledge and experience gained here will be extremely beneficial in performing the work detailed below.

I propose to build a small design support system, for use in a classroom setting in the Fall semester of 1998, that allows the limited use of rules in n-dim. At the start of the semester, users will be able to invoke an expert system shell from inside of n-dim, pass it data and rules that they have authored, and receive a result from the expert system. Later in the Fall term, I plan on attaching an expert system shell to each user's n-dim process to allow users to be able to write rules about data and events that they generate during an n-dim session. I will analyze the data collected from use during this semester, and, using insight gained from this first round of implementation, will perform this task again for the Fall semester of 1999. The second implementation of the design support system will allow rules to be written about data and events generated by any arbitrary agent in n-dim. This expert system shell will run continuously (like the database server) and will provide the inter-process communication capability required to allow rules to react to events generated by other agents in n-dim, as well as explicit time events.

With data gathered from these two semesters, I intend to show that allowing designers to write rules about data stored in a design support environment is useful and aids the group effort in collaborative tasks like engineering design. The preliminary project timeline can be seen in Figure 3. I believe that this work is feasible in the time period shown and that it makes significant contributions to the field of engineering design support.

Figure 3. Preliminary Project Timeline.

8 Bibliography

[Kenl97] Kenlon, J. "The Lowdown on PUSH", Taming The Net Online Magazine, (accessed October 1997), Tiger Leaf Communications, Inc., Pittsburgh, PA (1997).

2. In this context, "designer" takes on a full range of logical connotations: engineers, architects, writers (of documentation as well as of other sorts), managers, marketing people, etc., all can be designers [Levy93].

4. Conklin defines cognitive overhead as "the additional effort and concentration necessary to maintain several tasks or trails at one time." [Conk88].

13. The lack of a global clock can also play havoc with some methods of concurrency control in distributed groupware systems [Elli88].